I must be missing something here because I'm not sure I see the point in using onMM if you _also_ have to define each property in a <cfproperty> tag. If I'm going to have to define each property in a <cfproperty> tag, then I might as well just define the methods themselves. At least then I'd have a firm API. I use onMM so I don't _have_ to define my properties at all. And I use it sparingly, btw.
Assuming we're just talking about CF here, what is the advantage to using onMM and requiring a <cfproperty> tag for each property, over explicitly defining the getters and setters? On Wed, Jan 28, 2009 at 2:37 PM, Henry <[email protected]> wrote: > >> The only concern I have with oMM is that there are some properties >> that are meant to be private but oMM would allow ALL properties to be >> get and set. Right now I thought of two ways of handling this. >> Either override the getter/setter and throw an exception, or maybe add >> custom fields in cfproperty like gettable/setterable="false", and use >> getMetaData() to determine if the property should have getter/setter? > > Oh, just realized Kevin Roche has just tackled my problem: > http://www.objectiveaction.com/Kevin/index.cfm/2009/1/27/onMissingMethod-and-Abstract-Object--Part-2 > > > Henry > > On Jan 28, 10:33 am, Henry <[email protected]> wrote: >> Are you guys certain that oMM will be always less efficient? Didn't >> creation (and attaching) methods into an object is also expensive in >> CF8? Since beans needed to be created all the time, maybe the cost of >> creation of methods will offset the slightly inefficient oMM? I guess >> performance should not, in theory, affect how we construct our code, >> but at some point it does. >> >> The only concern I have with oMM is that there are some properties >> that are meant to be private but oMM would allow ALL properties to be >> get and set. Right now I thought of two ways of handling this. >> Either override the getter/setter and throw an exception, or maybe add >> custom fields in cfproperty like gettable/setterable="false", and use >> getMetaData() to determine if the property should have getter/setter? >> >> Again, I'm surprised so many of you uses Transfer. >> >> Henry >> >> On Jan 28, 6:06 am, Bob Silverberg <[email protected]> wrote: >> >> > My validate() method also returns a Result object. It has the following >> > methods: >> >> > setIsSuccess() >> > getIsSuccess() >> >> > addFailure() >> > getFailures() >> > ^- used to add errors (which I prefer to call failures), and to return >> > an array of failures. Failures contain metadata such as which >> > property failed, the type of failure, a custom message, etc.). >> >> > setTheObject() >> > getTheObject() >> > ^- the same as Brian's get/setDataObject() - returns the object that >> > was the subject of validation (a cloned object), which can then be >> > used in a view. >> >> > setSuccessMessage() >> > getSuccessMessage() >> > ^- this is available when there are no failures. >> >> > onMissingMethod() >> > ^- This allows me to add additional properties to the Result object at >> > runtime. This makes it reusable. For example, not only do I return a >> > Result object from my validate() method, I also return it from a call >> > to the upload() method in my FileSystem object. In that case, when a >> > file has been uploaded, if successful, in addition to calling >> > setIsSuccess() on the Result object, I can also call setServerFile() >> > to store the name of the ServerFile from the CFFILE output in my >> > Result object. >> >> > Looking at Brian's response, it's kind of spooky how similar mine is >> > considering that I'm pretty sure I've never seen Brian's object. Then >> > again, I have learned much of what I know from him. >> >> > Also note that I'm using this with Transfer, which makes most of the >> > other questions asked moot. >> >> > Cheers, >> > Bob >> >> > On Wed, Jan 28, 2009 at 8:12 AM, Brian Kotek <[email protected]> wrote: >> > > Mine typically has things like: >> > > setSuccess() >> > > isSuccess() >> > > These are ways to add existing errors or create an error in a specific >> > > format (typically property, message, className, and id) >> > > getErrors() >> > > addError() >> > > addErrors() >> > > createError() >> > > What to show if there are no errors. >> > > getSuccessMessage() >> > > setSuccessMessage() >> > > ID of the object that was successfully saved >> > > getSavedId() >> > > setSavedId() >> > > An object to use to repopulate the form in the event of failure, which >> > > keeps >> > > the user's entered data. So this is used instead of the "real" bean when >> > > the >> > > controller passes the data into the view. >> > > getDataObject() >> > > setDataObject() >> > > Hope that helps. >> > > On Wed, Jan 28, 2009 at 7:44 AM, Alan Livie <[email protected]> wrote: >> >> > >> @Brian, you said 'I do and have it return a Result object.' >> >> > >> Can I be nosey and ask what public methods are in your Result object? >> > >> :-) >> >> > >> I have things like Result.hasErrors(), Result.getErrorForField(), >> > >> Result.hasErrorForField(), Result.addError() etc >> >> > >> Always looking for improvements! >> >> > >> Alan >> >> > >> ________________________________ >> > >> From: Brian Kotek <[email protected]> >> > >> To: [email protected] >> > >> Sent: Wednesday, January 28, 2009 12:24:00 PM >> > >> Subject: [CFCDEV] Re: Questions on Design of Bean, what is your version >> > >> like? >> >> > >> On Wed, Jan 28, 2009 at 4:39 AM, Henry <[email protected]> wrote: >> >> > >>> - Do you generate setters & getters for each property, or use >> > >>> onMissingMethod()? >> >> > >> Use Transfer, which does all this for you. But if you don't, generate >> > >> them >> > >> so you have an actual API. >> >> > >>> - If you're using onMissingMethod(), does it look for cfproperties to >> > >>> check for valid property name and type? >> >> > >> See above. >> >> > >>> - Do you think a complex bean with lots of properties will be more >> > >>> efficient with onMissingMethod() or with good old getters & setters >> > >>> for each property? >> >> > >> No, using oMM() will always be less efficient. >> >> > >>> - Are methods generally in bean, or in Service layer (singleton) for >> > >>> better performance? >> >> > >> It depends on the method. Don't think about performance. If it is >> > >> related >> > >> to the behavior of the domain object, put it there. If it is related to >> > >> orchestrating interaction with multiple domain objects or other >> > >> services, >> > >> put it in the service. That said, the service should be as dumb as >> > >> possible. >> >> > >>> - Does the bean always stay in a valid state with restrictive setters? >> > >>> or do the setters and init() take in any type? >> >> > >> That's up to you. >> >> > >>> - Does the bean have validate() function? Does it return an array of >> > >>> struct of {type, message}? or are you using any validation framework? >> >> > >> I do and have it return a Result object. >> >> > >>> - Does it always have some other standard methods? Or does it extends >> > >>> some abstract/base bean? >> >> > >> Most often it extends an abstract bean or an abstract Transfer >> > >> decorator. >> >> > >>> - Do you set default values for properties? if so, outside or inside >> > >>> init()? maybe make use of cfproperty default field? >> >> > >> I only use cfproperty for Value Objects that are meant for something >> > >> like >> > >> Flex, and in that case I generate the VO and specify default values if >> > >> necessary. >> >> > >>> - Does it lazy-load? If so, how do you implement that? >> >> > >> Transfer will do this if you want it to. Implementing it yourself will >> > >> be >> > >> non-trivial. >> >> > -- >> > Bob Silverbergwww.silverwareconsulting.com > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
