I think that's very nice! Seems well suited to a fully compiled
language... flex? So you have DataTypeFacade.cfc which manages all the
types, and you inject EmailDataType.cfc, SSNDataType.cfc,
PipiPooPooDataType.cfc into it at app startup using Lightwire. Now
what I'm slightly unclear about is where you store the specific data
that describes each custom type instance. For example, if you have a
concept of a USER that has 2 properties: Email and SSN - would you
create a USER.cfc, compose it with DataTypeFacade.cfc, and store the
metadata for each property in there? If so, how would you pull out,
say, the form fields for SSN:
UserObject.getDataTypeFacade().showFields('SSN')?Cheers, Baz On Nov 12, 2007 4:53 PM, Peter Bell <[EMAIL PROTECTED]> wrote: > > Hi Brian, > > Thanks for answering – I missed Baz's question . . . > > Baz, > > There are a couple of things I do. Firstly, if you want to display a list > of 100 objects, I actually just instantiate a single bean which provides an > iterator (I called it an Iterating Business Object for the lack of another > term in the CF world) - there's a project somewhere on RIA Forge with sample > code. The benefit of this is you can still get and set properties, so you > can encapsulate your getting and setting logic within the bean, but you only > have to instantiate one bean, not 100 which (at least in the past) was a > real benefit in terms of performance. > > However, I also take it a little further. I have the concept of "custom > data types". Think about how much time you spend creating code that'll > display currencies correctly, that'll allow you to enter phone numbers in > three text boxes instead of one and that merges those three text boxes from > a form into a single field. Then add in any transformation code (to strip > all non-numeric characters from phone numbers, for example) and then the > validation code (validating dates are well formed, that phone numbers and cc > numbers have the right number of digits and so on). > > With custom data types, you can just say that a given property is a Date or > an Age or a US Phone Number or a WYSIWYG and they system will automatically > provide smart, parameterizable form fields, display code and form processing > code for handling it automagically so you can declaratively describe most of > your property specific rules and the framework will dynamically run the > appropriate code. In an ideal world, I'd create an object for each property > (so if User had firstname, lastname and Email, each would be an object) and > each property would extend the appropriate custom data type class (that's > how I'm looking to implement a Ruby version of my framework when I get some > time). In CF, within my bean I inject a DataTypeFacade singleton which I > pass the data type, the method type and any related parameters. It has all > of the singleton custom data types injected into it so you can reuse > property level code without having to instantiate an object for each > property. It's a little hacky, but all of the design decisions are > encapsulated within my base business object so it'd be easy to change and > the performance implications in CF of having a CF object for every single > property of every object are extreme enough that I'm happy with the solution > from a pragmatic perspective. > > Best Wishes, > Peter > > > > > On 11/12/07 7:29 PM, "Brian Kotek" <[EMAIL PROTECTED]> wrote: > > > > If I recall correctly, Peter loads up all the data into the object, but then > allows you to treat the object like an iterator, where each loop iteration > loads a new row of data into the object. So even though there is only 1 > instance, it keeps getting repopulated as you loop over a set of data > (query, array, etc.). > > On Nov 12, 2007 6:06 PM, Baz <[EMAIL PROTECTED]> wrote: > > > @Peter > What you wrote is very interesting. When you say you use singletons to > enhance performance, where do you store the specific instance data for > each property? Are you, perhaps, storing the metadata for each > property instance locally in the singleton in a native cf type (i.e. > query) then using that metadata to pass into the functions when > needed? > > Cheers, > Baz > > > > On Nov 11, 2007 6:41 PM, Brian Kotek <[EMAIL PROTECTED]> wrote: > > As always, it's a trade-off. In this case, if the advantage of having > email > > wrapped up into its own class is very high (perhaps the behavior of email > is > > expected to change often, or needs to be reused in many other classes), > then > > that advantage is worth the performance cost of creating it for the > objects > > that need it. However, I wouldn't just go do this with all properties of > all > > objects. It has to be done for a valid reason, with an understanding of > the > > pros and cons. > > > > In general, small classes ARE preferred. Smaller objects are much more > > likely to be cohesive. The larger an object gets, the more likely it is > that > > is might be doing too much and the more likely that future changes will > be > > more difficult to make. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" 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/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
