Another option (but I wouldn't recommend it until you've played with the
others)
I have a render.cfc that does all of my rendering. It includes in the init()
method a variables.display = THIS;
When controller is ready it passes my PageRequest "bucket" object into
render.page(PageRequest). That method includes the appropriate cfm template
which can then include a #display.ContentArea("ContentAreaName")# for each
content area which calls the render.cfc's contentarea method which in turn
includes the appropriate cfm screen for each content area.
To avoid the name space issues, I make render.cfc a transient so it is
created for each request (the cost is quite small) so I don't have to worry
about scoping issues within my included cfm templates.
This approach is a little unusual, but it was done to optimize the
readability of the API for the designers who have to create the templates.
Seems to be working out quite well and an example of hw many different ways
you can solve this kind of problem.
Personally, I'd still vote for MG or M2 unless you had a really good reason
not to use them!
Best Wishes,
Peter
On 4/2/07 5:45 PM, "Jaime Metcher" <[EMAIL PROTECTED]> wrote:
> Joe,
>
> 1. As Sammy says, always to a CFM page that calls the controller CFC. You
> can directly invoke a CFC, but I can't think of a good reason to do it that
> way, and there are some downsides (like not being able to invoke a cached
> instance, and having to reference the URL scope in the CFC).
>
> 2. As Tanguy says, it's a good idea to relocate after an update (usually a
> form post) so the refresh button won't redo the update. Having said that,
> it's very much a matter of style and personal preference how you invoke the
> view. I think the choices look like:
>
> a) cfinclude the view CFM from within the controller
> b) in an MVC framework like model-glue, put a reference to the view CFM in
> the config file (which amounts to a cfinclude, I think)
> c) do a cfmodule call to the view CFM from within the controller
> d) get the contoller to return the name of a view module, then call that
> within the page
> e) as for a), c) or d), but have the view code in a CFC instead of a CFM
>
> I've done all of these, but the first one seems to be most widespread. You
> just have to be aware of your namespaces if you do this - the modular
> programmer in me doesn't like it, but it is easy and fast.
>
> Jaime
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Lakey
>> Sent: Tuesday, 3 April 2007 1:48 AM
>> To: [email protected]
>> Subject: RE: [CFCDEV] newbie: needs an opinion on component structure
>>
>>
>> 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]
>
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]
