Best Practice Suggestions?

[creativecashflow]

Hey CF World,

I have to revamp an online order process. The process is broken into 4 steps.

The app as it exists today was built by a different developer and for the life of me, I have wasted about 5 hours trying to figure out exactly what the person is doing in the code just so I can make some basic tweaks to the process.

Could anyone offer what might be considered today's best practice for a step by step order process?

The thought is, if the user could complete step 1, upon clicking next the data elements of the form would be validated and then they would be taken to step 2, etc, etc... until the end where upon submission, the order would then be written to the database and next process triggered internally.

Should I have one page that upon submit of step 1 cycles back to itself, processes the data and then loads a separate div of info for step 2 or...?

Any suggestions would be great.  Thank you so much in advance for your help, I sincerely appreciate it.

Ciao'

D.

[JaneUK]

I'm not going to attempt to answer the user interface side, that's not my area of expertise.

In terms of validation, ideally this should occur at three levels

1) Client-side - immediate response. Traditionally this is Javascript. For instance, if the user tries to enter a letter into a numeric field, they get feedback as soon as they press the button.

1a) Client side - on submit. Any extra validation (blank mandatory fields, comparison of fields) that doesn't require a trip to the server. Also traditionally Javascript.

2) Application level. Assume that the user had Javascript disabled, and none of your previous validation had happened. Also, there are tools such as Firebug that let them edit your HTML before running it: adding extra items to a SELECT, for instance. Redo all previous validation!

This is also where you check things against your database - and parameterise any database interface. SQL injection is a Bad Thing. Do as much as you can via stored procedures called by CFCs, and if your code only needs read access, use a datasource that only has read access.

3) Database level. Assume they've somehow got in via a route other than your application: maybe a malicious or careless employee using command-line SQL. Enforce all business rules and all data integrity constraints at database level: constraints, triggers, whatever your database provides.

Sounds horribly paranoid, doesn't it? But that trick of editing the SELECT is done by 13-year-olds hacking games, so if you're dealing with real money and adults, it's the sort of thing you have to allow for.