I'd like to add that there are those who argue that writing getters and 
setters isn't more work because you can just use a code generator. I 
agree with that. But for me the less code I have to manage (whether it 
was generated or not) the better.

-Tony



Tony Garcia wrote:
> One of the knocks against using oMM instead of manually writing getters 
> and setters is that such components don't have an API. Using cfproperty 
> tags to define your properties is one way to address this issue. I 
> personally like this approach (my method is similar to Kevin Roche's) 
> and I still think that writing cfproperty tags are less work than 
> writing out a setter and a getter for each one, but to each his own.
>
> Bob Silverberg wrote:
>   
>> 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
>>>>>         
>>>>>           
>>
>>   
>>     
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to