http://jroller.com/comments/kwiersma?anchor=why_you_should_use_coldspring
--Kurt
On 11/22/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote:
It helped me :O) - I have been wanting to try and use ColdSpring with
MG and haven't gotten around to it. Your point on how to incorporate
Seans auto-wire controller is very handy indeed.
thanks
Bill
On 11/22/05, Chris Scott < [EMAIL PROTECTED]> wrote:
> Here's a few points that I can help you with, inline:
>
>
> > 1. Have I set up the model-glue controller correctly ? It seems a
> > bit arduous to have every "public" event do a check and then
> > forward to a "private" event that actually implements the
> > functionality of the event that was originally called. Is anyone
> > doing anything else? Am I missing something ?
>
> How about having the SecurityController preform this check in
> onRequestStart, then configure it with a 'public events' list that
> you can check the current event against? This way can only preform
> your security check for the 'secure' events. In the latest BER of MG
> you can retrieve the name of the current event being processed in a
> controller with 'arguments.event.GetEventHandlerName()'. Wether or
> not you need that depends on how you are calling the
> SecurityController. In onRequestStart, you could just call
> 'arguments.event.getValue('event') as well, since that method will
> only fire on the first event, however if you are going to explicitly
> send the controller a message in any public or private event, use
> 'arguments.event.GetEventHandlerName()'.
>
> > 3. Am I correct in saying that because I have specified
> > singleton="True" for my datasource thingy (bean.... whatever you
> > want to call it), that Coldspring will cache the object and return
> > the same object each time I call getModelGlue().getConfigBean
> > ("PlatypusDS") ? (Thus alleviating the need to store it in the
> > application scope).
>
> You are correct here. I just want to point out, though, that the
> default behavior of ColdSpring is to return beans as singletons. You
> don't need to specify singleton="true".
>
> > 4. Am I also correct in saying that if I was to create a "Staff"
> > bean, that I would need to specify singleton="false", to ensure
> > that a new staff bean was created each time I request one?
>
> I'm not sure you really want to create beans with ColdSpring, unless
> you are setting up a complex business object with dependencies. Here
> I would use the makeEventBean() method of the MG core.Event . In a
> controller, 'agruments.event.makeEventBean('com.yourCompany.Staff',
> [optional list of fields])'. First off, the event cfc will
> automatically populate the bean's fields from values in the event
> (form fields), also there are less objects involved in creating you
> beans in this scenario.
>
> > 5. Finally, am I correct in saying that if I had a
> > "viewStaffDetails" event (and let's ignore security and assume that
> > the user is authenticated for a moment), that my controller would
> > have a method that did something like this;
> >
> > <cffunction name="getStaffDetails" access="Public"
> > returntype="void" output="false" hint="I am an event handler.">
> > <cfargument name="event" type="ModelGlue.Core.Event" required="true">
> > <cfset var myStaffMember = getModelGlue().getConfigBean
> > ("StaffDAO").read(arguments.event.getValue(staffid),getModelGlue
> > ().getConfigBean("StaffBean"))>
> > <cfset arguments.event.setValue("StaffMember",myStaffMember)>
> > </cffunction>
>
> Here you are doing things in a slower manner that necessary. Your
> StaffDAO should be a property of the controller (I don't know which
> controller we are talking about in the method above). You can do one
> of two things here. In the init method, retrieve the StaffDAO from
> ColdSpring and store it in variables:
>
> <cffunction name="init" access="public"
> returntype="ModelGlue.Core.Controller" output="false">
> <cfargument name="ModelGlue" type="ModelGlue.ModelGlue"
> required="true" />
> <cfset variables.staffDAO = arguments.ModelGlue.getConfigBean
> ("StaffDAO") />
> <cfreturn this />
> </cffunction>
>
> OR, instead of explicatelly retrieving the StaffDAO, you can just add
> a setter for StaffDAO in the controller
>
> <cffunction name="setStaffDAO" access="public" returntype="void"
> output="false">
> <cfargument name="StaffDAO" type=" com.yourcompany.StaffDAO"
> required="true" />
> <cfset variables.staffDAO = arguments. StaffDAO />
> <cfreturn this />
> </cffunction>
>
> Then you can use Sean Corfield's AutoWire controller to handle the
> wiring for you (see next)
>
> >
> > From what I have gathered so far, ColdSpring actually acts like a
> > factory, allowing me call on it to create / get DAO's / Beans etc
> > whenever / wherever I need them. (and ensures that only the
> > appropriate amount of instances are created at any given time) as
> > well as doing some other nifty stuff.
>
> Yes the heart of ColdSpring is a supped up bean factory, however
> there are other technologies layered on top of it. Primarily in your
> case here, is the ability to use the coldspring.modelglue.AutoWire
> controller (define it as the first controller in your mg config file)
> to automatically provide your controllers with their ColdSpring
> managed dependencies.
>
> I hope any of this helps!
>
> -Chris
>
>
> ----------------------------------------------------------
> 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]
>
>
>
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
----------------------------------------------------------
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]
