As to where to put things, Generally I tend to think if it thus:
If it applies to only one "page" in traditional coding, put it into the
listener for that event.
If you can generalize something that happens on 3 or more pages into
something that could be used across the system, putting it into a filter
might be a good way of handling things.
If you have something which applies to EVERY request (say security or
logging) then a plugin is probably the way to go
The Services should handle interaction with multiple DAOs to define
relationships for "Higher Level" objects (i.e. when I have a shopping cart,
and add an item to it, the service should just recieve an object ("bean")
with the shopping cart and an collection of items, and should be able to
tell the CartDAO and the ItemDAO and the CartItemAffiliationDAOs all what
they need to do to make the database reflect the changes to the Cart.
The DAOs and gateways should be simple passthroughs to Stored Procs, or
Dynamic SQL if you're not using Stored Procs.
The View should only contain <cfoutput>, <cfloop> and very sparing <cfset>
for turning things in the event scope into local variables.
The Model is where you should define relationships. For example, your
"Cart" object should have an "AddItem" method, that shows that there's a
relationship between a cart and an item, and a "setCustomer" method, to show
that there's a relationship between your customers and your carts.
However, that's just my experience, and what works well for me. The fun
thing about OO is that 30 different developers can have 50 different ways of
doing things, and all of them valid.
Adam Ness
On Wed, Jun 17, 2009 at 6:11 PM, Teaman <[email protected]> wrote:
>
> I writing my first action filter for a form submission. When an error
> in data entry is detected for example, how is the error msg handled?
> I assume you simply return false on the DAO or Gateway method called
> by the listener. But if a variety of error conditions are possible,
> such as missing field entry or input too long or file already exists,
> etc... I'd think this info would need to be passed back too.
>
> Can someone please explain how this is normally handled?
> Where is the error msg text normally specified? Only in the View?
> Currently my view file is planning to look for an error msg in the
> event obj. So somewhere it's got to be put into the event obj. Is
> that with a putArg? Where is that call usually made?
>
> This is the biggest struggle I have with learning Mach-II. I don't
> know where to put the code. If you consider each of the code snippet
> locations as "buckets" (the config .xml file event-handler, the
> listener, the filter, the gateway, the view, the model, etc.) it's
> sometimes hard to know where to put some piece of the code.
> Particularly a variable... like a parameter or property. Do I set it
> in the Properties section, or in the event-handler or in the filter/
> listener or in the component or in the method??? Are there "rules of
> thumb" to follow?
>
> I guess this is really two threads in one. Sorry... being effficient.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/
Wiki / Documentation / Tickets:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/
-~----------~----~----~----~------~----~------~--~---
