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]
