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