1. Data storage: I wrote the old application to store the client data in the session scope but I'm starting to think I should temporarily store the data in the database instead. There is a *lot* of data and it could be broken down into a number of classes to structure it all nicely. Given that almost all of the fields will be used by each visitor (and there will be confidential information in parts inc SSN, payment details, etc) should I keep it as one large table or normalize it? What have others done for this?
I think the biggest problem with this approach is cleanup. If a user aborts the process half way through, how do you remove the data? Do you have a cron script that clears out the database periodically? I personally find the approach a little messy. I prefer storing it in the session scope. If you really think there is "too much data" for the session scope, I'd write a simple one pager that creates an approximation of the full dataset and then use a tool to simulate typical user load. See what happens to CF server RAM utilization. You might be worrying a lot more than you need to.
2. Data normalization: Stemming from #1, any suggestions on how much I should normalize the CFCs? I'm figuring it will all stem from a Visitor class which would have an associated Order class, but would there be enough benefit to e.g. splitting off to do an Address class. Also, to keep it nice and clean where should I put the validation code, in the model CFCs or the controller - I'm guessing they'd be part of the model and the controller would call them, correct?
A fine-grained object model promotes more reuse in your code base. An Address object could be reused in several places in your application or even across applications. Also, this can be varied independently from your DB's normalization to some extent. For instance, your Visitor can have a 1-1 relationship with the Address object but the data for both could be stored in a single table instead of having separate VISITOR and ADDRESS tables. This is nice because you avoid an unnecessary table join. Validation can be done many ways. I would create a validation method for each valid state your business object might have. For instance, an object could have validateForSave() and validateForSubmit() methods, where "save" and "submit" might be different steps in a process flow. Usually these map to use cases pretty well. I think the easiest way to switch this into the Controller is to have your BusinessObject expose the validation method publicly, return a ValidationResult object, which your Controller examines to determine whether it needs to re-render the view or continue by calling the save() method or whatever. Another way to handle it is to throw Exceptions when validation fails, but I'm not sure what's the easiest way to do this in CF.
3. Flow control: I personally hate it when you are going through a form, type in something it doesn't like and are given an error message on the *subsequent* page, the old "you had an error, go back and fix it" routine, rather than on the page the errors were on. The problem with splitting it up into several fuseactions was that if on page 1 I set the xfa to page 2 it would be messy to jump back to page 1 to display the error messages, especially when I was storing all data in the session as you can't write data to the session if you are doing a cflocate jump. I'm thinking the MVC approach and IoC / II could help with this, but in practical terms how should I structure it? UPDATE: the <results> tag should do what I need for this.
Create an event-handler that displays the form. Have it submit to an event that performs validation. Depending on the result, either re-display the view (with errors) or proceed with processing the page, invoking business logic, etc. You can create a private event-handler that renders the view that is used by both of your public event-handler. HTH, -Cliff ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
