Hi Joe,
Typically the user action will go to a front controller - a single file (in
cf, by convention, usually "index.cfm" which calls the appropriate
controller(s) to handle a given action. However, there is a story for using
a pseudo-page controller where you have a "about-us.cfm" page stub that
pre-sets certain properties and then calls the front controller as that
works well for content management style solutions - but if you're just
getting started with this, start with front controller and go from there.
I use includes within a rendering cfc which provides some nice (but subtle)
benefits in terms of a literate API for designers so they can say things
like #display.ContentAred("Sidebar")# and it works, but most people have a
framework which calls the controller receive the name of the screen(s) to
display and include them.
I'd STRONGLY suggest looking at the best practice frameworks out there.
Check out how Model-Glue and Mach-II do these things, and unless you have a
compelling reason not to, consider using them - at the very least for our
first few projects until you get a feel for how they work and then you MAY
want to consider writing your own custom framework.
Best Wishes,
Peter
On 4/2/07 11:47 AM, "Joe Lakey" <[EMAIL PROTECTED]> wrote:
> I like this explanation of what a controller is and does; it clarifies
> the controller concept a little for me. I have a couple of follow-up
> newbie questions:
>
> 1. Should the user action (i.e. clicked link or submitted form) go to a
> controller cfc or to a cfm page that interacts with the controller cfc?
>
> 2. How should the controller cfc direct the browser to the view layer:
> cfincluding the view page, redirecting with cflocation, or something
> else?
>
> Thanks,
>
> Joe
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
>> Of Jaime Metcher
>> Sent: Thursday, March 29, 2007 7:17 PM
>> To: [email protected]
>> Subject: RE: [CFCDEV] newbie: needs an opinion on component structure
>>
>> Janet,
>>
>> "Controller" is a pretty generic term for the code that first
>> gets control when the page loads and then works out what to
>> do next. Generally a controller will do something like:
>>
>> 1. Gathers/detects user inputs and/or actions (e.g. user
>> clicked on a link, user typed some text into a form field and
>> hit submit)
>> 2. Modifies the systems state based on what the user did
>> (e.g. updates breadcrumb nav data, inserts something into a database)
>> 3. Works out what the user should see next and sends them
>> there (e.g. redirects to a thank you page, calls a display
>> module to redisplay a form)
>>
>> You can implement this any number of ways, but there are some
>> general principles that apply to all well-behaved controller code:
>>
>> 1. Don't put the code in the page - at least put it in a
>> module if not a CFC.
>> 2. Don't directly manipulate the database or other system
>> state. The controller should call another a set of modules
>> and/or CFCs (aka "the model") to do this.
>> 3. Don't directly display anything. Once again,the
>> controller should call another set of modules and/or CFCs
>> (aka "the view") to do this
>>
>> Once you've separated out all the model and view code, the
>> remaining controller code can be very simple. It's really
>> just dealing with application flow.
>> .
>> Jaime
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Behalf Of J MacKay
>> Sent: Friday, 30 March 2007 8:48 AM
>> To: [email protected]
>> Subject: RE: [CFCDEV] newbie: needs an opinion on
>> component structure
>>
>>
>> Jaime,
>>
>> Yes, I think I was trying to make the DAO smarter than
>> it needed to be.
>>
>> I've been focusing on the persistence aspect and the
>> lower level stuff. Honestly, I'm not sure I understand
>> controllers. Can you explain a bit more? Do I need a controller here?
>>
>> Janet
>>
>>
>>
>> --
>>
>>
>> ________________________________
>>
>> Don't pick lemons.
>> See all the new 2007 cars
>> <http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE0OGRsc3F2BF9
>> TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3Y2Fycw--> at Yahoo!
>> Autos.
>> <http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE0OGRsc3F2BF9
>> TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3Y2Fycw-->
>> You are subscribed to cfcdev. To unsubscribe, please
>> follow the instructions at http://www.cfczone.org/listserv.cfm
>>
>> CFCDev is supported by:
>> Katapult Media, Inc.
>> We are cool code geeks looking for fun projects to rock!
>> www.katapultmedia.com
>>
>> An archive of the CFCDev list is available at
>> www.mail-archive.com/[email protected]
>>
>>
>> You are subscribed to cfcdev. To unsubscribe, please follow
>> the instructions at http://www.cfczone.org/listserv.cfm
>>
>> CFCDev is supported by:
>> Katapult Media, Inc.
>> We are cool code geeks looking for fun projects to rock!
>> www.katapultmedia.com
>>
>> An archive of the CFCDev list is available at
>> www.mail-archive.com/[email protected]
>>
>
>
> You are subscribed to cfcdev. To unsubscribe, please follow the instructions
> at http://www.cfczone.org/listserv.cfm
>
> CFCDev is supported by:
> Katapult Media, Inc.
> We are cool code geeks looking for fun projects to rock!
> www.katapultmedia.com
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
