|
Hi
Nando,
The
principle for the flex/flash/web services integration is that it would be nice
if your HTML CF app would expose the same events to other interfaces, so if
someone wanted to write a flash shopping site with a back end persistent cart,
all it would have to do is call your Cart.AddtoCart facade method, passing the
documented parameters and getting back well formed data that it could consume
and format to display the updated cart without knowing anything about your
business objects or model. Also allows you to write a .NET client app for more
efficient data entry and to only have to write the display logic and
connect up the display to a set of web services (it gets a little trickier in
practice, but that is the theory).
I'm
the same looking at my old code - a veritable italian feast!
Model
Glue is a great framework. If you're going to use an OO framework, I think it is
a great choice. If you're going to write your own framework, it should be one of
the reference frameworks you disect before you start coding.
Best
Wishes,
Peter
Hijacking the thread here a bit ... That
(the enterprise pattern stuff) is a little over my head at the moment. I'm not
sure, from a cursory look at Flex, which i'm really excited about, if you
could (or should) control it from from within a CF application. I thought your
service layer or facade would just provide access to your model for a
flex/flash app for instance, especially in that it resides on the client
side.
But again, this is way over my head at the moment. Wish it
wasn't, but it is.
In any case, the principle of encapsulating the
code that tells other code what to do is still there, in whatever approach you
take. It's not something that i've always done, for sure. (Usually i think i'm
taking an efficient shortcut when i write spaghetti.) But whenever i come back
to it, it doesn't feel like it's been done well. I still fall for it
sometimes!
That's why i like ModelGlue so much as an example of a
Controller and MVC. I scanned Doug Hughes' MG/Reactor blog (forgot to mention
him ... i really appreciated looking at his blog application!) and within just
a few short minutes i knew how the whole thing worked. Wow. I like
that!
When i come back to some of the stuff I myself have written,
which i should *at least* be familiar with, and i'm confused for a significant
amount of time ... well, let's not talk about that!
n :)
Peter
Bell wrote:
Hi
Nando,
Agreed 100% with everything except for the idea that having a facade
to the model creates spaghetti code.
There are two distinct functions the controller usually handles in an
HTML app - all the HTML specific stuff, and orchestration. If you have only
one controller layer that always calls functions to get session information,
check for cookies and the like, try calling that using a web service or
flash remoting and see what happens. Of course, you could replicate your
orchestration code in the flash movie and in your HTML controller and have
flash access your model directly, but then if your business rules for
orchestration changes, you have to change them in two
places.
To
me, it just makes perfect sense to have a facade to handle orchestration and
to have a seperate controller to handle all of the HTML specific stuff if
you're ever going to expose your business methods to non-HTML consumers. And
it's not like this is a pattern or approach I made up out of thin air - I'd
say it's a pretty well established pattern for enterprise
architecture.
While you're pointing to resources, I'd also add Martin
Fowler for some less CF specific, but interesting
articles.
Best Wishes,
Peter
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: [email protected]
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 [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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
--
----------------------------------------------------------
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]
--
----------------------------------------------------------
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]
|
