Hi, I suppose what I'm looking for is a value object which is particular to a session, representing entity data and I have the following two questions:
1. My value object represents/shadows data which is sitting in a user entity bean. If some of the attributes represent the user's preferences and are to be used as prepoulated 'defaults' in the html form, should I be manually synching up the formbean with the VO so that the jsp draws on the form bean values instead of the VO's values? 2. When struts populates/updates the formbean on html:form submission, should I be synching up the VO from the formbean?(Assuming tomcat and jboss are always local to each other(in this particular app) perhaps inter-tier invocations are not that big an issue so making the call to the entity bean via a session facade instead of using a VO bean might be ok. Any thoughts?) I lied there's actually a third question ... 3. If I have a VO which is read only, is there a pattern which I can look at which will provide for updating the VO in the web-tier when the entity is updated in the business (ejb) tier? I suppose we'd be looking at some form of event notification similar to that portrayed in the Petstore app(1.1.2). (I am currently using the book you mentioned but haven't read it all yet:-)) Jim -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 04 July 2002 18:30 To: Struts Users Mailing List Subject: Re: should I use form bean and javabean for the same data? On Thu, 4 Jul 2002, Jim Clayson wrote: > Date: Thu, 4 Jul 2002 17:58:03 +0100 > From: Jim Clayson <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: should I use form bean and javabean for the same data? > > Hi, > > I read somewhere on this list sometime ago that one should bear in mind that > struts form beans should be considered to be part of the view in your > run-of-the-mill MVC struts app and that they should only be used for > prepopulating a form and/or reporting surface level validation errors. > > Does this mean that I shouldn't ever be setting the values on the form bean > inside my action class or wherever I perform my business logic? If this is > true (and please could someone confirm this), should I be using a vanilla > javabean to model the data for use outside of the view? > It's hard to be very descriptive without a particular example, but in general I would say that model-tier data is generally exposed to the view tier as JavaBeans. If you are using some of the popular design patterns for multi-tier applications (such as those in "Core J2EE Patterns" by Alur/Crupi/Malks), this object will typically be a Data Access Object, or a Value Object, or (a more current term) Data Transfer Object. It's ok to expose model data directly to the view tier for display-only use, by saving it in a request or session attribute where the view page can get to it. For the incoming data that modifies things, I generally set up my applications like this: * "Setup" action creates and prepopulates the form bean, as well as setting up any other beans that are needed for the display. It then forwards to the "input form" page. * The "input form" page as an <html:form> tag pointing at the "Process" action, with input fields that match the properties of the corresponding form bean. In most cases, the properties of the form bean will be strings. * The form bean has a validate() method to check for things like required fields and conversion errors (such as entering "1a3" into a field destined to be an integer). If any errors are found, Struts redisplays the "input form" page for you, with the exact values that the user entered (even if they were wrong). Note that we have *not* corrupted any model tier objects with invalid data. * The "Process" action is called only after validation is successful. It can perform any additional checks it needs, and then interacts with the business objects to perform whatever updates are needed. (In trivially simple Struts apps, the business logic is sometimes embedded in the Action -- it's better to segregate this logic into separate business objects, though). * At this point, the form bean gets thrown away, because it has completed its purpose. For request-scope form beans, this happens automatically when the request completes. For session-scope form beans, you have to deliberately remove the coresponding session attribute. > Maybe I'm missing something here. > > Any assistance will be much appreciated. > > Jim > Craig > __________________________________________________________ > > <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> > > Jim Clayson > > > Infogain Limited > > > tel: 01628 580600 > fax: 01628 580610 > email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > web: www.infogain.com <http://www.infogain.com/> > > > > Disclaimer: Neither this e-mail nor any attachment places any legal or > contractual obligations on Infogain Limited. Any reproduction, disclosure or > dissemination beyond the intended addressees is strictly prohibited save for > the legitimate business purposes of Infogain Limited and its clients or > partners. > > __________________________________________________________ > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
