Project History

Project History

Fabrice created Kanji Koohii (previously "Reviewing the Kanji") in late 2005 and maintained the website up to this day in early 2017. This website started in the days of php4, long before modern client side Javascript frameworks, SPAs, and even before the explosion of smartphones and tablets!

As such the code quality is all over the place. Some parts are good, some parts are bad. In my opinion it's still very maintainable today but of course it makes a lot more sense to me than to someone who first dives into the code.

At this stage the symfony 1.x backend is "good enough" to drive the templates and the best thing we can do imho is write modern ES6 / VueJS code on the front end side while keeping the backend in a maintainable state.

Since the mobile & responsive update I added a Webpack / Babel / VueJS build. This allows to write new functionality with modern ES6 and VueJS.

There's definitely room for improving the backend, using Composer, etc. It's just not my main area of focus but those contributions are very welcome.

Some explanations about Kanji Koohii's code:

• Symfony's ORM is not used. Since I was learning I created a lightweight MySQL interface. The good news is that it's modelled closely after Zend Db so I think it could realistically be refactored to the real Zend Db but at this point it may not be worth the hassle as it "works". AFAIK it is secure due to escaping everything by programmatically building queries etc. There shouldn't be a single line of code in the whole repo which builds queries in a string!

  The downside to this database layer is that you can't use a symfony plugin as is, most symfony plugins such as an oauth plugin will rely on the ORM for storage.

• 90% of the front end was written around 2008-2010 when I was quite proficient with OO Javascript. Today it's really tedious to write code like that, so all new functionality should use Vuejs and ES6 wherever possible.

• Since the website has been through one complete refactoring to symfony, not everything could be ported easily. The database API is one example, there are a few hacks related to the helpers. Since my helpers were very similar but not 100% the same as symfony. At this point it doesn't seem worthwhile to refactor, eg. helpers for forms, when we could do that with client side code.

• Much of the validation is pretty basic because as a solo developer it was really tedious to update validation config files the symfony way. My approach usually is to cast values, or do some regexp. If the data is not in a format expected, I didn't waste time returning meaningful messages to someone tampering with the data, hence when something doesn't validate the code usually returns a http 404 of 500.

• There is no test suite. The website is not incredibly complex. In terms of API my approach was to try and document the input and output parameters. I tend to avoid == operator in favor of === everywhere I can, to make the code less error prone. That means defining explicitly when a function returns false, or null. I found using vague comparators like == or empty() eventually turns the code into a big mess.