value bean

[Tom Jerry <to...@gmail.com>]

would you please give some useful links / insights in using value beans for
get & set methods of properties and use of getAttribute ( ) , setAttribute (
) methods. I have seen that for eg: in login module, apart from having
LoginAction and LoginForm classes, we have LoginValueBean class also. I am
sort-of confused. Please explain.

Re: value bean

[Tom Jerry <to...@gmail.com>]

In LoginForm class itself, I have placed the get and set methods. What
should be contained specifically in LoginValueBean class ????? I am sort of
confused.

On 9/30/06, Tom Jerry <to...@gmail.com> wrote:
>
> I want an example in terms of coding please.
>
> On 9/29/06, Eddie Bush <ea...@swbell.net> wrote:
> >
> > Good morning, Tom!
> >
> > Thinking back to how and why we have a form bean, you'll recall that
> > it's
> > wise for us to use String properties in our form beans.  This is so that
> > we
> > can avoid type conversions in capturing user input.  This ensures that
> > we
> > don't lose any information that the user has supplied us - even if it's
> > invalid (or will not convert to the desired type) - so that we can give
> > the
> > user the option to correct, rather than re-type information they are
> > providing.  This is just good design :-)  If you've ever gone through a
> > long
> > form that cleared its values for every mistake you made, you'll
> > appreciate
> > doing this!
> >
> > The value bean (or value object, or data-transfer object, or ... <insert
> >
> > other synonym here>) has the goal of encapsulating a set of data.  This
> > bean
> > should have "real" types.  For example, if there were a property named
> > "name", which would presumably be of type String, it would be String.
> > However, if you had a date field, say "dateOfBirth", you would make it a
> > Date here (your form bean would capture this as a String).  You'd then
> > have
> > some "glue" (possibly BeanUtils) that does your conversions from one to
> > the
> > other.  Failure to convert from form bean fields to value bean fields
> > would
> > be one possibility for sending the form back to the user for editing.
> >
> > Thinking back to how and why we build applications in layers (think
> > MVC),
> > you'll recall that our model should be a separate, self-contained
> > "critter".
> > This way, we can write multiple front-ends for a single model.  This
> > model,
> > hopefully :-) facilitates designing/coding against an interface, rather
> > than
> > just some set of functions that get called.  I say interface because it
> > implies a more carefully put together "thing".  That implies that you
> > would
> > have classes to act as containers for the attributes of the various
> > objects
> > you found in your problem domain.  These containers are (or _can_ be)
> > your
> > value beans!  This makes a lot of sense when you think about the rule of
> > layers:  Dependencies go down; data goes up.  So your value bean is a
> > model
> > component that you use in your application (web, in this case) layer
> > (dependencies go down) to retrieve data from your model (data goes
> > up).  As
> > it happens, you also probably use these objects to send data to your
> > model.
> >
> > Using the standard getXXX and setXXX methods is done to follow the
> > JavaBeans
> > pattern.  This allows your beans to be used dynamically.  For example,
> > if
> > you're writing your pages (I'll assume JSP) using some type of tag
> > library,
> > rather than just coding in them :-) you'll appreciate following this
> > pattern.  If you don't follow that pattern, you may get unexpected
> > results.
> > Sometimes, even a small deviation from this pattern can cause hours of
> > fun
> > for the unaware developer.  I've had several occassions to help my
> > colleagues find this subtle oversight :-)
> >
> > Hope that helps some!
> >
> > Eddie
> >
> > ----- Original Message -----
> > From: "Tom Jerry" < tom.snow.jerry@gmail.com>
> > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > Sent: Friday, September 29, 2006 6:24 AM
> > Subject: value bean
> >
> >
> > > would you please give some useful links / insights in using value
> > beans
> > > for
> > > get & set methods of properties and use of getAttribute ( ) ,
> > setAttribute
> > > (
> > > ) methods. I have seen that for eg: in login module, apart from having
> > > LoginAction and LoginForm classes, we have LoginValueBean class also.
> > I am
> > > sort-of confused. Please explain.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>

Re: value bean

[Tom Jerry <to...@gmail.com>]

I want an example in terms of coding please.

On 9/29/06, Eddie Bush <ea...@swbell.net> wrote:
>
> Good morning, Tom!
>
> Thinking back to how and why we have a form bean, you'll recall that it's
> wise for us to use String properties in our form beans.  This is so that
> we
> can avoid type conversions in capturing user input.  This ensures that we
> don't lose any information that the user has supplied us - even if it's
> invalid (or will not convert to the desired type) - so that we can give
> the
> user the option to correct, rather than re-type information they are
> providing.  This is just good design :-)  If you've ever gone through a
> long
> form that cleared its values for every mistake you made, you'll appreciate
> doing this!
>
> The value bean (or value object, or data-transfer object, or ... <insert
> other synonym here>) has the goal of encapsulating a set of data.  This
> bean
> should have "real" types.  For example, if there were a property named
> "name", which would presumably be of type String, it would be String.
> However, if you had a date field, say "dateOfBirth", you would make it a
> Date here (your form bean would capture this as a String).  You'd then
> have
> some "glue" (possibly BeanUtils) that does your conversions from one to
> the
> other.  Failure to convert from form bean fields to value bean fields
> would
> be one possibility for sending the form back to the user for editing.
>
> Thinking back to how and why we build applications in layers (think MVC),
> you'll recall that our model should be a separate, self-contained
> "critter".
> This way, we can write multiple front-ends for a single model.  This
> model,
> hopefully :-) facilitates designing/coding against an interface, rather
> than
> just some set of functions that get called.  I say interface because it
> implies a more carefully put together "thing".  That implies that you
> would
> have classes to act as containers for the attributes of the various
> objects
> you found in your problem domain.  These containers are (or _can_ be) your
> value beans!  This makes a lot of sense when you think about the rule of
> layers:  Dependencies go down; data goes up.  So your value bean is a
> model
> component that you use in your application (web, in this case) layer
> (dependencies go down) to retrieve data from your model (data goes
> up).  As
> it happens, you also probably use these objects to send data to your
> model.
>
> Using the standard getXXX and setXXX methods is done to follow the
> JavaBeans
> pattern.  This allows your beans to be used dynamically.  For example, if
> you're writing your pages (I'll assume JSP) using some type of tag
> library,
> rather than just coding in them :-) you'll appreciate following this
> pattern.  If you don't follow that pattern, you may get unexpected
> results.
> Sometimes, even a small deviation from this pattern can cause hours of fun
> for the unaware developer.  I've had several occassions to help my
> colleagues find this subtle oversight :-)
>
> Hope that helps some!
>
> Eddie
>
> ----- Original Message -----
> From: "Tom Jerry" <to...@gmail.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Friday, September 29, 2006 6:24 AM
> Subject: value bean
>
>
> > would you please give some useful links / insights in using value beans
> > for
> > get & set methods of properties and use of getAttribute ( ) ,
> setAttribute
> > (
> > ) methods. I have seen that for eg: in login module, apart from having
> > LoginAction and LoginForm classes, we have LoginValueBean class also. I
> am
> > sort-of confused. Please explain.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: value bean

[Eddie Bush <ea...@swbell.net>]

Good morning, Tom!

Thinking back to how and why we have a form bean, you'll recall that it's 
wise for us to use String properties in our form beans.  This is so that we 
can avoid type conversions in capturing user input.  This ensures that we 
don't lose any information that the user has supplied us - even if it's 
invalid (or will not convert to the desired type) - so that we can give the 
user the option to correct, rather than re-type information they are 
providing.  This is just good design :-)  If you've ever gone through a long 
form that cleared its values for every mistake you made, you'll appreciate 
doing this!

The value bean (or value object, or data-transfer object, or ... <insert 
other synonym here>) has the goal of encapsulating a set of data.  This bean 
should have "real" types.  For example, if there were a property named 
"name", which would presumably be of type String, it would be String. 
However, if you had a date field, say "dateOfBirth", you would make it a 
Date here (your form bean would capture this as a String).  You'd then have 
some "glue" (possibly BeanUtils) that does your conversions from one to the 
other.  Failure to convert from form bean fields to value bean fields would 
be one possibility for sending the form back to the user for editing.

Thinking back to how and why we build applications in layers (think MVC), 
you'll recall that our model should be a separate, self-contained "critter". 
This way, we can write multiple front-ends for a single model.  This model, 
hopefully :-) facilitates designing/coding against an interface, rather than 
just some set of functions that get called.  I say interface because it 
implies a more carefully put together "thing".  That implies that you would 
have classes to act as containers for the attributes of the various objects 
you found in your problem domain.  These containers are (or _can_ be) your 
value beans!  This makes a lot of sense when you think about the rule of 
layers:  Dependencies go down; data goes up.  So your value bean is a model 
component that you use in your application (web, in this case) layer 
(dependencies go down) to retrieve data from your model (data goes up).  As 
it happens, you also probably use these objects to send data to your model.

Using the standard getXXX and setXXX methods is done to follow the JavaBeans 
pattern.  This allows your beans to be used dynamically.  For example, if 
you're writing your pages (I'll assume JSP) using some type of tag library, 
rather than just coding in them :-) you'll appreciate following this 
pattern.  If you don't follow that pattern, you may get unexpected results. 
Sometimes, even a small deviation from this pattern can cause hours of fun 
for the unaware developer.  I've had several occassions to help my 
colleagues find this subtle oversight :-)

Hope that helps some!

Eddie

----- Original Message ----- 
From: "Tom Jerry" <to...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Friday, September 29, 2006 6:24 AM
Subject: value bean


> would you please give some useful links / insights in using value beans 
> for
> get & set methods of properties and use of getAttribute ( ) , setAttribute 
> (
> ) methods. I have seen that for eg: in login module, apart from having
> LoginAction and LoginForm classes, we have LoginValueBean class also. I am
> sort-of confused. Please explain.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org