i agree with Wes

I've seen many implementations with decorators which are ok as long as packages 
and version are known
e.g. @Decorator could be referencing any one of a number of interfaces
(personally I prefer implements interface as there is no ambiguity which 
package interface you are using)
IDE's (netbeans/eclipse) are ok as long as they dont change the code to behind 
the scenes conform to a framework/spec they support..a good idea that unless a 
known FactoryMethod or IOC container is specifically implemented the engineer 
should be hands on the code 
I agree on the use of accessors and mutators (vs a public declaration..)

Anyone else?
Martin
______________________________________________ 
Disclaimer and confidentiality note 
Everything in this e-mail and any attachments relates to the official business 
of Sender. This transmission is of a confidential nature and Sender does not 
endorse distribution to any party other than intended recipient. Sender does 
not necessarily endorse content contained within this transmission. 


> Date: Fri, 1 Aug 2008 09:17:46 -0400
> From: [EMAIL PROTECTED]
> To: user@struts.apache.org
> Subject: Re: Is this obvious ?
> 
> Although I agree that less code is good, there gets to be a point of
> terseness that you should be wary of. I would suggest keeping getters
> and setters on your struts 2 actions for a few reasons. First, Struts
> 2 Actions are simple POJOs for the most part, and by following the
> JavaBeans conventions allows the objects to be usable by more than
> just struts. Libraries like commons-beanutils and many others will
> work easily with objects following the JavaBeans conventions. Although
> it's not a hard requirement, it may help you in the future and most
> modern IDEs have helpers to generate getters and setters.
> 
> -Wes
> 
> On Fri, Aug 1, 2008 at 3:55 AM, Lyallex <[EMAIL PROTECTED]> wrote:
> > Good Morning
> >
> > I have an Action called SomeAction
> > it has a field called someInt
> >
> > public class SomeAction extends ActionSupport{
> >
> >   private int someInt;
> >   public int getSomeInt(){return someInt;}
> >   public void setSomeInt(int someInt){this.someInt = someInt;}
> >
> > }
> >
> > when this action is invoked from a form with value convertable to an
> > int, then in the renderer I get hold of someInt like this
> > <s:property value="someInt/>
> > This only works if there is a getter for someInt
> >
> > If I go on to edit someInt in a form with this tag in it
> > <s:textfield name="someInt"/>
> > then the value of the field is set because I provide a setter for someInt
> >
> > If I do this
> >
> > public class SomeAction extends ActionSupport{
> >
> >   public int someInt;
> >   //no setter or getter, the attribute is public
> >
> > }
> >
> > Then everything works fine
> >
> > The question is
> > If less code good, more code bad then why bother with the setters and 
> > getters.
> >
> > This is not a question about the merits of encapsulation and
> > information hiding in Object Oriented systems
> > It is a question about the reason for not making fields public in a
> > Struts2 Action.
> >
> > TIA
> >
> > Lyallex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> 
> 
> -- 
> Wesley Wannemacher
> President, Head Engineer/Consultant
> WanTii, Inc.
> http://www.wantii.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

_________________________________________________________________
With Windows Live for mobile, your contacts travel with you.
http://www.windowslive.com/mobile/overview.html?ocid=TXT_TAGLM_WL_mobile_072008

Reply via email to