On 9/10/05, Richard Rodseth <[EMAIL PROTECTED]> wrote:
Ok, forget all OOP best practices as CFMX is a puppy onto its own ;) heheh.
Hmm, i'll take stab at this :)
To me, when a user submits a form and passes simplistic (formatting and ui validation rules) it then gets pushed forward into server-side land, that being CFMX. CFMX has a translation/mapping process which takes care of extracting the FORM.scope from a primitive state into a more "known" state, ie allocating the properties into a known "FormBean". This FormBean is then passed into a Listener, which is then deserialized and placed in correct corrosponding BO/TO according to the Models request.
Ie, the Mach-II "Auto-Bean" in my book is something thats tightly coupled with the context of how the UI intends to use a Form and has no relivance at all to how the model will then use that said bean... meaning, keep the two seperate currencies.
The Listeners job is to again, translate this weird mutated Auto-Bean into something of more weight / value (i'm typically using TO/BO solutions, where i would via the listener, instantiate a TO, pass that into the model, and from there its up to the model to either validate that TO by feeding it into the BO for validation (if an error occurs, throw exception).
An example would be umm.. saving an Multi-tabbed Invoice.
Ingredients:
- x Number of Costcodes can be attached (lets say some sexy DHTML is in play here)
- x Number of Approvers can be attached to an Invoice (again, DHTML)
- Invoice General Properties (ie costings etc)
Now, if one were to "Save" this invoice, one could argue that once the UI has initially allowed the submission to take place (ie simplistic UI validation / formatting takes place) this data is stored within an "Auto-Bean/TO" which simply put keeps it nicely packaged and some raw / primitive data manipulation may occur.
From here, its passed into a Listener, the Listener is looking for this Auto-Bean and it knows how to unpack it properly and store in a more strict typed TO for the model. It then feeds this data into the Model, and listens for any exceptions to be thrown.
(Note: I prefer to trade in TOs within Listener, in that to me i still regard the Listener as part of the view, thus prefer to keep the BO out of the picture within this zone as i tend to use the model via two UI's... CFMX for Unit Testing via Mach-II solution and FLEX for actual UI. So essentially the Listener and FlexGatewa/Facade.cfc act similiar in accessing the Model)
Well sort of, look at FLEX examples with CFMX. If you follow the same rules in FLEX as you do wtih HTML/DHTML solution you're fine, in that the UI (aka Form) couldn't give two hoots how the data is persisted, and its up to the final tier to figure that logic out.
(I'm reposting since this showed up in the archive, but I didn't get
it in my mailbox)
I'm new to CF and mach-ii (though not to OOP) so forgive me if this is
an FAQ which my Googling missed.
Ok, forget all OOP best practices as CFMX is a puppy onto its own ;) heheh.
The mach-ii-info sample, which seems like a nice piece of work, uses
UserTO as the bean on a user form. But it seems to me a form bean
should be a separate beast which contains string-only properties like
the form, along with storage for error messages and a validate()
method. Having UI-level stuff like error messages and validate()
doesn't seem right in the TO.
Hmm, i'll take stab at this :)
To me, when a user submits a form and passes simplistic (formatting and ui validation rules) it then gets pushed forward into server-side land, that being CFMX. CFMX has a translation/mapping process which takes care of extracting the FORM.scope from a primitive state into a more "known" state, ie allocating the properties into a known "FormBean". This FormBean is then passed into a Listener, which is then deserialized and placed in correct corrosponding BO/TO according to the Models request.
Ie, the Mach-II "Auto-Bean" in my book is something thats tightly coupled with the context of how the UI intends to use a Form and has no relivance at all to how the model will then use that said bean... meaning, keep the two seperate currencies.
The Listeners job is to again, translate this weird mutated Auto-Bean into something of more weight / value (i'm typically using TO/BO solutions, where i would via the listener, instantiate a TO, pass that into the model, and from there its up to the model to either validate that TO by feeding it into the BO for validation (if an error occurs, throw exception).
An example would be umm.. saving an Multi-tabbed Invoice.
Ingredients:
- x Number of Costcodes can be attached (lets say some sexy DHTML is in play here)
- x Number of Approvers can be attached to an Invoice (again, DHTML)
- Invoice General Properties (ie costings etc)
Now, if one were to "Save" this invoice, one could argue that once the UI has initially allowed the submission to take place (ie simplistic UI validation / formatting takes place) this data is stored within an "Auto-Bean/TO" which simply put keeps it nicely packaged and some raw / primitive data manipulation may occur.
From here, its passed into a Listener, the Listener is looking for this Auto-Bean and it knows how to unpack it properly and store in a more strict typed TO for the model. It then feeds this data into the Model, and listens for any exceptions to be thrown.
(Note: I prefer to trade in TOs within Listener, in that to me i still regard the Listener as part of the view, thus prefer to keep the BO out of the picture within this zone as i tend to use the model via two UI's... CFMX for Unit Testing via Mach-II solution and FLEX for actual UI. So essentially the Listener and FlexGatewa/Facade.cfc act similiar in accessing the Model)
Avoiding this would mean that the listener that is reponding to the
form submission would have to perform a mapping from UserForm to
UserTO or directly to User. Methods in User that take a UserForm
wouldn't seem right either.Suppose the user form has a bunch of checkboxes for groups the user
belongs to. I picture the form bean containing a comma-separated
string of group ids, while the TO (or perhaps it's a separate
groupsTO) contains a ColdFusion list of group ids, and the User BO
translates this to updates to the users and groups tables.
Make sense? Any state of the art samples involving more complex forms
and multi-table updates?
Well sort of, look at FLEX examples with CFMX. If you follow the same rules in FLEX as you do wtih HTML/DHTML solution you're fine, in that the UI (aka Form) couldn't give two hoots how the data is persisted, and its up to the final tier to figure that logic out.
Thanks,
- Richard
----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
--
Regards,
Scott Barnes
http://www.mossyblog.com ----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
