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" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
