> doing some thinking here, yeah amazing for a Monday eh? I have an > application with a multi-part form. My first thought was to use CFCs to > model the form, having a parent CFC with child CFCs for each 'section'. > Now, to do this all data in a CFC has to be exposed/manipulated. IE > getters/setters for every property in the CFC, or use of > setProperty/getProperty methods. After thinknig on this I'm convincing > myself that this is poor use of CFCs, that is, there does not seem to be a > compelling reason to use OO stuffs for this. I can see creating a CFC or > two for the biz logics, but not the form itself, have say a > formhandler.cfc. > > Thoughts from the masters on this? Is having a CFC with a one-to-one > mapping of form fields to properties in the CFC worthwhile or just > overhead? I'm guessing this is a loaded opinionated question, but still, > I'd like to see some thoughts.
No masterful thoughts here... but anyway: The concept, from an OO standpoint seems sound: you've modeled your problem down to its "atomic units". A form object contains many different widget objects (input, select, textarea, radio, checkbox, etc). You would (I'm assuming) have methods in the widgets/form allowing for custom validation routines, display options, submission types and so forth. In that sense its "good OO" - you've abstracted your complex business logic into easy-to-implement component interfaces. You gain a lot with this: 1) The ability to add new validation or submission types or improve old ones without (in theory) affecting any of the implementation code. 2) The ability to change the way all implemented code appears via the object model. Just change the display methods and everything follows suit. 3) The model allows you to do full type/validation checking and instance checking: you can design it in such a way that a "MyInput.cfc" can't exist outside a "MyForm.cfc" thus ensuring integrity. MyForm.cfc could do all sorts of useful things: check for name conflicts among children, define and implement common validation routines (just as CFFORM constructs it's client side validation framework) and so forth. 4) You can standardize the entire flow: your custom form object can, for example, submit in such a way as to populate an implementation CFC - something like "MyFormSubmital.cfc" which would abstract the process of storing or otherwise using the form information (for example creating a more application appropriate data structure of the submitted data into grouped subsets). 5) You can easily add new, non-standard form elements. Want a "related selects"? A combo-box? An in-out pick list? You can create CFCs to manage all of the interface complexity. To the implementer it's as easy as using an input box. There's a lot going for such an idea. The problems/issues I see are: 1) Designing things the "right" way in CFCs will sometimes kill you: using all the proper component setters/getters can (depending on the number of them and the complexity) sometimes kill performance (we're talking about this in another thread). I just got over doing this: built a well-integrated, gloriously self-validating object model out of CFCs. Worked beautifully - literally brought a tear to me eye. Then I added data and performance tanked. I "fixed" it by replacing some of my well-oiled, cooperative code with nasty (but much, much faster) direct sets of properties. 2) Is it really worth it? Having such a library at the end can be insanely useful: but building it right will take a lot of work an effort. Is it really that useful to you? This is one of those things I'd love to see adopted as a community project: something we could all contribute to (once the framework were built and documented adding new form elements, new presentation styles or new validation routines could be added at any time). 3) Maintaining your standards may be difficult. First, to be really successful with this you have to HAVE standards. ;^) That gets back into the "is it worth it" question since documentation and defining your standards can take a while. CFCs also don't offer any way to force adherence to standards (type checking is a great first step - but interfaces would be nicer!) This may not be a problem but even just among me, myself and I I've found I sometimes have trouble enforcing my rules. ;^) I guess in the end what I'm saying is that what you've described sounds like an excellent use for OO programming... but isn't, maybe, all that suited to CFCs. Then again maybe it is. For my part I'd LIKE to see this work, but after my recent experiences I'm just not sure if it would. Jim Davis ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
