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 <[EMAIL PROTECTED]> wrote:
I want an example in terms of coding please. On 9/29/06, Eddie Bush <[EMAIL PROTECTED]> 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" < [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] > >
