On Tuesday, February 19, 2013 5:15:18 AM UTC-8, Chris Blackwell wrote:
>
>
> It shouldn't really be the case that your controller methods ends up being
> massive, if it is, then I'd hazard a guess that you're doing too much in
> your controller when really that code should be moved into a service layer.
>
>
It's not so much there is complex logic in the controller, just that the
steps are broken out to facilitate reuse of the methods. Here's what I
mean:
<broadcasts>
<message name="needToProcessClass/>
<message name="needToValidateClass/>
<message name="needToSaveClass/>
</broadcasts>
And in the controllers:
<cffunction name="doProcessClass" returntype="void" output="false"
access="public">
<cfargument name="event" type="any" />
<cfset var objClass =
arguments.event.makeEventBean(arguments.event.getValue("objClass")) />
<cfset
objClass.setClubId(arguments.event.getValue("objCurrentClub").getId()) />
<cfset arguments.event.setValue("objClass", objClass) />
</cffunction>
<cffunction name="doValidateClass" returntype="void" output="false"
access="public">
<cfargument name="event" type="any" />
<cfset var objClass = arguments.event.getValue("objClass") />
<cfset var error = objClass.validate() />
<cfif arrayLen(error)>
<cfset arguments.event.getValue("msg").setFromCollection(error)
/>
<cfset arguments.event.addResult("invalidClass")>
</cfif>
</cffunction>
<cffunction name="doSaveClass" returntype="void" output="false"
access="public">
<cfargument name="event" type="any" />
<cfset var objClass = arguments.event.getValue("objClass") />
<cfset getClubService().saveClass(objClass) />
<cfset arguments.event.getValue("msg").reportSaveSuccess('Class
saved successfully!') />
</cffunction>
I do this because in the admin we may not validate but we want to reuse the
same process and save code so this lets me reconstruct things. In the
example I'm working with here, I want to basically lock from the process to
the save step which is what Dan and I were discussing.
Dan - to your point, certain times I would probably want both. Either deny
the second request or just queue it. In most cases it's idempotent so a
second request won't cause a problem so long as it runs after the first.
Brian
--
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" group.
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/model-glue?hl=en
---
You received this message because you are subscribed to the Google Groups
"model-glue" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
