Hey
Joe,
Many
thanks for the post - makes perfect sense. So the controller is just the
"plumbing" to help the appropriate model and view to work with an HTTP page
request. I also have a facade level for orchestration and customization of
method calls (with rules based page and request specific parameter
overloading so different pages can return slightly different results sets or
field lists using the same underlying model calls).
Do you
also define session and cookie re-scoping to be part of the controller to
make the model request type agnostic (browser page request vs. flash remoting or
web service)?
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----Hey Peter,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart
Sent: Monday, June 12, 2006 7:32 AM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Do I Really Need A Controller?
Fusebox, MG, and M2 are all "front controller" frameworks - where every request goes through a central pipeline. The index.cfm is acting as the entry point for the front controller, and this front controller is acting to control the flow of the application. In this case, the "control of flow" is most easily illustrated in MG where you can simply look at a given event-handler tag and see what views and what other event-handler it's going to run.
(The opposite of front controller is "page controller," where every page has its own controller layer (such as code-behind in ASP.NET).)
What the "orchestration" elements (in Model-Glue, the 'listener functions' on the controllers) are doing isn't really orchestration in my terms. If I have a model that's complicated enough where my controller functions have to do some heavy manipulation of multiple model elements to accomplish a task, I'm better off writing a true facade for my model so that other clients to the application (like a maintenance script of a Flex app) can use the same logic easily.
What those elements are doing is the simple data pushing necessary to abstract the model from the views. Basically, all the listener functions should serve to do is ask the viewstate (URL and FORM scopes) for information, hand it to the model, and hand this back. Typically, it's a really simple task, but on complex forms where you may have entry of multiple records and you've got to sort out data by examining form field names the controller can begin to have more logic, but it's definitely controller logic because it deals with getting an organizing data from the view in order to pass it to the controller.
That help any?
-Joe
On 6/10/06, Peter Bell <[EMAIL PROTECTED] > wrote:Hi All,Nando, got me thinking about wording here. If you look at model glue, there is an index.cfm that receives the requests and then there are the event handlers defined in XML. With Fusebox there is again the index.cfm and then there are the the circuits and their associated fuse actions. In both cases there is a file that handles all of the stuff you need to handle for an HTML request/response and another set of files (whether code or XML) that describe the orchestration required to interact with the model and the view(s) to return.It seems to me that both the index.cfm and the set of XML files or scripts are undertaking the controller function. I was wondering if anyone had a good word to describe what the index.cfm is doing vs. what the orchestration elements are doing?Any ideas much appreciated!Best Wishes,
Peter-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Nando
Sent: Saturday, June 10, 2006 12:03 AMTo: CFCDev@cfczone.org
Subject: Re: [CFCDev] Do I Really Need A Controller?Ummm ... something to say here.
What you'll *always* need, no matter how you break your code apart, is some bit of code that tells the other bits what to do and when to do it.
Now, you can spread that out all over the place, CodeChunkA tells CodeChunkB to do something and then CodeChunkB tells CodeChunkC and CodeChunkD to do something, and then CodeChunkA tells CodeChunkE and F to do something and so on until you get to CodeChunkZCZR ... but then when you or someone else comes along in 5 or 6 months and looks at that, they'll have a really hard time figuring out how it all works.
Coding in this style has come to be known in some circles as "pasta" of the long stringy kind. Spaghetti. It's a very Italian way of dealing with things. Everybody tells everybody else what to do. (Ciao Massimo, just joking a little! Don't take me seriously ;-)
So in the example above, we don't have a single (or several) well defined controller(s), but we still have chunks of code telling other chunks of code what to do and when to do it.
So ... you always need that "hey you, do this" stuff in your code. The only question is if you encapsulate it in one place, or spread it all around.
Many programmers, even Italian ones, seem to feel after a few years of experimentation that they are much better off encapsulating that necessary "hey you, do this" stuff in one place in their code, so they can easily come back to it down the line and see fairly quickly how the whole thing works.
So no, you don't need *A Controller*, but you will always need chunks of code telling other chunks of code what to do.
Nando :)
PS ... A good way to understand how a controller works is to take a good look at model glue. The controller is implemented in a very simple and straightforward way as ModelGlue.xml and the controller cfc's. I don't think many of us on this list would be able to implement a decent MVC app from scratch without a framework to guide us. So i wouldn't start there, unless you are very gifted at implementing abstract ideas in code from scratch.
I have a friend who teaches artistic painting classes. He always has someone in the class who comes up to him and tells him they're having trouble coming up with something to paint. So he tells them, always, "Relax, Just copy what i'm doing." And he turns the painting he's working on and points at it with a smile so the student has a good view of it.
The student goes back and starts copying. But the funny thing is, my painter friend tells me with a big grin on his knowing face, "they always paint something totally unique."
The only trick out here is to choose carefully who you "copy" from! Here's a short list from this copy cat:
Hal Helms (his newsletters)
Joe Reinhart (his tutorials but you have to search his blog for them, the arf framework, the model glue framework)
Sean Corfeld (his sample apps)
Ben Edwards (the machII framework)
Once you've been copying for awhile, if you're gifted, you might graduate to being an originator. But don't worry if it takes you a little while to get there. :)
Peter Bell wrote:Yep. Controller is indeed traffic cop. Also, if there is EVER any chance of
a non-HTML interface to your site (web services, flash remoting, whatever),
you will want two elements to the controller. A "framework" piece will
handle the junk you need to handle to read and speak HTML with a web browser
and the "orchestration" piece will call the right model methods in the right
order based upon business rules in a way that does not assume there is a
HTML request (think sessions, cookies, form variables, URL variables, HTML
as part of the response messages, etc.).
Best Wishes,
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] On Behalf
Of Aaron Roberson
Sent: Friday, June 09, 2006 3:19 PM
To: CFCDev@cfczone.org Subject: Re: [CFCDev] Do I Really Need A Controller? So, you are saying that I should submit my form to the controller, and then the controller will run the email evaluation and send an error if not valid, or pass the form structure to the service to be inserted in the database if the email is valid. Is that correct? >From what I gather from your example, I think I am beginning to see how the "traffic cop" works... -Aaron On 6/9/06, Dustin Tinney <[EMAIL PROTECTED]> wrote:
In that case my controller would have somethign like this...
if(NOT hasValidFields(attributes.form))
{
redirectToErrorPage();
}
model.storeInformation(attributes.form );
sendConfirm(attributes.form.email);
On 6/9/06, Aaron Roberson <[EMAIL PROTECTED]> wrote:
I just send a confirmation email, I don't really want to test the
visitor to see how badly they want my newsletter... ha, ha.
-Aaron
On 6/9/06, Dustin Tinney <[EMAIL PROTECTED]> wrote:
Do you send your user a "verify" email or a "thanks for
subscribing email"?
On 6/9/06, Aaron Roberson <[EMAIL PROTECTED]> wrote:
I have an email subscription form on my website that visitors
can fill out and subscribe to our newsletter. I have created a
subscriberBean.cfc with getters/setters and an email validation
method, a subscriberDAO.cfc with CRUD methods, and a service
that creates a DAO object and a gateway object and passes
arguments to the DAO and the gateway (this is all based on Matt
Woodwards
CF.Objective () example and Peter Farrell's code examples from
CFWeekly
1.10).
It seems to me like the view would interact with the service,
which would perform my CRUD operations and return my the query
results from my gateway. If so, what do I need a controller for?
I've heard that controllers act as traffic cops, but I'm not
sure what that means. If my view is validating form field
entries, and my model is validating form field entries, and my
view is getting everything it needs from the service layer, what
do I need a "traffic cop" for?
Thanks for your feedback and suggestions!
-Aaron
On 6/9/06, Dustin Tinney <[EMAIL PROTECTED]> wrote:
Yes would be the answer to your question about needing a
Controller. However with out knowing what your doing a little
more It's hard to give direct examples of WHY you need it.
On 6/9/06, Aaron Roberson <[EMAIL PROTECTED]> wrote:
I have been plunging head first in to OOP (into a wall, I
should
say...) and I am trying to put all the pieces together so that I
can
begin implementation.
Anyways, I am wondering if I need a controller layer in my
design pattern? I really don't like the idea of using a
configuration file (xml or index.cfm) and wiring everything
to it like a fusebox, so I am staying away from frameworks.
I have been learning about seperating my business model into
beans, DAO's, gateways and services and I think I like the
abstraction that offers. However, it seems to me like my
views can interact directly with the service, making a
controller layer unneccesary. Is that correct, or am I lost
again?
P.S. I don't entirely understand what all a service does, so
I do have some questions about the service layer, but I will
start a seperate thread for that. I would have some
questions about the facade layer, but I don't have a clue
how to use that so I don't even know where to begin with the
questions regarding that.
Thanks,
Aaron
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org 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/cfcdev@cfczone.org ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
--
Get Glued!
The Model-Glue ColdFusion Framework
http://www.model-glue.com ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org
