Internet Bandaid   [RSS Feed]

Archive for January, 2014

Accordion Forms – Dangers

without comments

You’ve seen those accordion forms? You know how a form is broken up into multiple sections. You see section one, and after filling it out, it slides up and the second section slides down, etc…

Whenever you build an accordion form, careful consideration should be paid to validation. You definitely need BOTH server side validation to protect the database and client side validation to assist the user in filling out the appropriate values. You can’t do with just one and not the other. Why? Because:

a) if you stick with only server side validation to protect the database, it means that on failure, you will need to reload the page with the appropriate accordion step open. The tricky part is writing code to open the appropriate accordion step. I’ve seen developers set “flags” to determine which accordion step shoudl eb opened upon failure. This can get very messy especially if multiple sections need to open, in which case, defeats the whole purpose of having an accordion. Your controller code will bloat up like crazy …you’ll wish your accordion was just broken up into multiple pages instead, with the controller code decoupled between each step. When doing server side validation on accordion form, if you rely on reloading a form upon failed validation and showing error messages, that’s a clear indiction you should not be using accordion form.

b) if you stick with only client side validation, so that you can validate within each accordion step, sure it’s great for the user, but hackers can easily disable javascript, and start attacking your system. Or even more likely, the client is on a browser that has poor support for certain javascript features.

In conclusion, if you use an accordion, be expected to do A LOT more work. It’s not as simple as just picking a jquery plugin and slapping it to your projet. Be prepared to double up your validation work.

If you’re on a tight timeline, keep each step that normally appears in an accordion section as their own page. Then it’s very clear what each page is for, instead of one massive controller trying to manage too many accordion steps.

Written by John Lai

January 22nd, 2014 at 1:21 am

Posted in Uncategorized

setTimeout(‘somecall()’,0) to force a redraw of the screen

without comments

On several occasions, I’ve had websites that were animation heavy. And sometimes on the first page load, I would have a javascript function like renderSomething(); that will draw and position elements nicely. But sometimes, when the page first loads up, things still aren’t drawn precisely . Sometimes I can fix this by doing a setTimeout(‘renderSomething();’,0) right in the document.ready event handler, to force a redraw of the screen.

Written by John Lai

January 18th, 2014 at 6:48 pm

Posted in Uncategorized

Common Causes of Unmaintainable PHP Apps

without comments

I work as a contract web software developer and I also take on a lot of LAMP projects. I’ve inherited a lot of PHP projects that are extremely hard to maintain. When a client complains to me about security issues, stability issues, data integrity issues, or the substantial costs to maintain or upgrade the system, I find it’s commonly caused by one or several of the following issues:

1) There is no separation between model view and controller. Instead, presentation code, business logics etc… are all found in the same block.

2) Text for human eyes should only appear in the database, html/xml view files, or language files. It should not appear in controller code, javascript code, css, config files etc… Imagine how difficult it would be for a high school student with no software development training to translate a website if he has to search through PHP strings in massive loops just to replace some text.

3) Not clearing POST information after sending an HTTP Request that updates or creates records in the database. So that if someone accidentaly presses refresh on the browser, it would trigger an unintended update/create. This is so terrible, and is the cause of duplicate records. Please just use a header() to redirect to a success page, so that it drops your previous POST info.

4)Using mysql() instead of a safer data abstraction library like mysqli, PDO etc… Please start using parameter binds to reduce likelihood of SQL inject.

Written by John Lai

January 18th, 2014 at 5:42 pm

Posted in Uncategorized

NOTES : Mysql 5.5+ vs. PostgreSQL 9.0+

without comments

I’ve been thinking about whether to start developing with Postgresql. I was even entertaining the idea of replacing the mysql database of one of our Drupal projects with postgresql database.

My primary motivators for considering this were:
- a business decision – there are some investors and business individuals, who at the mere mention of mysql, thinks your product is cheap and not scalable
- the reputation mysql 4.x attracted as a very poor relational database technology if you expect it to be ACID compliant

I did a little research and talked to a few people. Turns out mysql 5.5 has come a long way to being a database that might support medium to larger organization needs. From what I’ve read so far, performance of postgresql 9.x isn’t that much greater than mysql 5.5+. See here. Additionally, there are a lot more open source tools built with support for mysql, but not necessarily postgresql. This is particularly true of drupal modules.

So now, I don’t have a very strong argument for migrating existing projects off of mysql over to postgresql.

Written by John Lai

January 14th, 2014 at 12:53 am

Posted in Uncategorized

Drupal is good…when you’re NOT using it

without comments

Hey guys, when it comes to module development, I think we’re going to stop relying on the drupal tools and instead develop with a traditional MVC approach within the drupal framework. For all future module development, things will be done in the following manner:

  1. Every feature will be comprised of two modules: i) module_name_model and ii) module_name_controller . All data request and data manipulation happens in the model module. All data transmission to templates happen in the controller module.
  2. All template files will exist in templates folder in the module_name_controller folder. In the future, templates might become a module on its such as module_name_templates.
  3. Controllers will access template files via php’s ob_start() and ob_get_clean() functions.

The objective of this set up is to improve the following:

  1. Make it easier to see what model functions exist and can be used by the entire project.
  2. Remove dependence on drupals theme() functions, and blocks etc… to reduce barrier to using drupal
  3. Too often, the a single modules does way too much

A few people asked, "Why not leave the model functions within the module?"

Answer: The reason is because we intend for the model functions to be re-useable model functions/objects that can be used by the rest of the project.

Although it wasn’t asked, but naturally, the follow up question should have been, "Let’s say you have a module called Financial System (that has controller and view files). According to your approach, that means you will need a module called Financial System Model. A possible issue with this is that the Financial System probably is not a single model or data object. Instead, it would be a large collection/library of other models. Imagine looking in /sites/all/modules directory and seeing a list of modules like: user_model module, user_role_model, photo_model, financial_system_model. In this list, the first three model are rather atomic (as in it’s very clear what business object in the real world it represents), but the last module…the financial_system_model…it is a behemoth module that groups many atomic models. This mires code homogeneity. Either have atomic model modules right in the modules folder, or have modules of libraries of models, but NOT both. When code is not homogenous/consistent, you’re encouraging software entropy."

My answer to that is – That’s COrrect. Let me back up, what i failed to mentioned originally was that I was speaking from the point of view of a person who is in the middle of re-factoring a very large project. Making ONE model module for every ONE controller module is only an intermediate step for re-factoring purposes. At the moment, we do not have a clear picture of how our model should be designed (which of course is not a good thing, and it stems from my limited understanding how best to use drupal in a git controlled dev environment as opposed to a db controlled dev environment). We can either have each model module be atomic (the first few items you mentioned), or each module be more like a library of models (the financial system model). We should eventually pick one approach or the other, but not both.

For now, we just want to separate the model from controller and view. Once we’ve done that, we can think about next steps.

Right now, the focus is to improve code readability. Any developer entering the system should not have to think twice where to write his/her new code.

Written by John Lai

January 12th, 2014 at 1:31 am

Posted in Uncategorized

Command line for sql server

without comments

Command LIne for SQL Server?

Looks it has a cli: “sqlcmd”

at first glance looks quite similar to (but certainly a little different than e.g. “go” not “;”) mysql

Written by John Lai

January 3rd, 2014 at 11:30 am

Posted in Uncategorized