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