I'm not saying that Christian did this the wrong way, but I don't understand
why. Doesn't using your CFC as your action page turn that action page into a
display page?
Not at all. The handler CFCs redirect to presentation pages. None of the components do any type of output or presentation.
Not to mention that if you're doing any kind of error checking, you've lost all your form elements in a cflocation unless you did a forward.
The framework allows for all data submitted through a form or as URL parameters to be retained and redisplayed on any presentation page along with appropriate error messages. If you have Pollster installed, give it a try. Create a poll with a name and no options, or options and no name. You won't lose any of your data and you will have error messages in the correct places.
I know this is a somewhat unconventional ColdFusion framework, but it has worked out very nicely. Here is a summary:
There are three layers of components: entities, managers and handlers.
1. Entites
Entities contain all the SQL in the entire application. As a rule, there can not be SQL anywhere else. A typical entity has save, update and delete functions. The classic example is the user entity with saveUser, deleteUser and updateUser.
2. Managers
Managers perform higher level tasks by using one or more entities. For instance, there might be a order manager with functions like createOrder, updateOrder, deleteOrder, or getOrderStatus which makes use of multiple entities. Managers glue together entities using transactions. For instance, if you were to call deleteUser on the UserManager, the UserManager might start a transaction, call deleteOrders to get rid of all the user's orders (since you can't have orders in your database for a nonexistent user), call deleteUser to get rid of the user, then finish the transaction. Managers often contain transactions, but never any SQL.
3. Handlers
Handlers are like the controller in a more conventional MVC framework except they are customizable. They are the components that forms are submitted to. All handlers inherit from a super handler (which you can think of as the controller), so the only code in a handler implementation is code that is specific to processing the specific form that gets submitted to it. The handler framework automatically handles redirection to presentation pages, error messages and preserving data submitted in the request (form or url variables).
The last part of the application are the presentation pages, written entirely in CFML with no components and no logic other than that which pertains directly to presentation. Every .cfm page in the application is either a presentation page, or gets included by a presentation page, leaving all of the business logic and SQL well encapsulated behind three layers of components.
The architecture has worked out very well. I have made several changes to Pollster (in fact, I am in the process of working on a new version right now), and the framework is proving quit extensible. Now that you have some background, I'm curious why people seem to believe that submitting to a component is not a good idea. A new instance of the component is created on each request, however I am generally not shy about creating component instances and have not run into performance issues yet. Are there other downsides that I'm not seeing? Is the alternative being proposed to use ColdFusion pages instead? Isn't it cleaner to use ColdFusion pages for presentation purposes only?
Christian
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
