Hi, > So I'm tryin to figure out what happens when I generate a CMP that uses > dataobjects and Struts forms. Everything's so bright that i gotta wear > welding goggles or something. Except one thing: > > My form has fields that aren't going to be persistent fields. Think about > the "type your password twice" type forms. The second password isn't saved, > it's just compared in the action to make sure it matches. But since the form > uses dataobjects, all of the fields must exist in the dataobject. This isn't > a problem, but the dataobject uses @ejb:persistent-field in the source bean > to trigger generation of the field in the dataobject.
The second password should be in the struts form only and compared to the other struts password field in a struts action. So it has nothing to do in a data object that is there to send back the info to the ejb tier. To be complete I would say that automatic merging of struts form and data (or value) objects can never be accomplished at 100% else that would say you are linking your UI tier and your domain/persistence tier. Xdoclet can autogenerate a lot for you for the simple cases but it will never be able to do everything and your example is exactly an example where the 2 tiers must differs. Sometimes you have to code a bit, hey Xdoclet does not want to steal your job :) (to respond to Ara) Value Objects are there only to bring some fields of EJB together to a "light" value object. I think most of CMP 2 containers provide lazy loading of database fields, for example a field that contains a 2GB video is only loaded in entity bean "instance" when the field is accessed. If data object is used, the 2GB field will be extract from the database. It is better to build a Value Object that takes all but this field. Etc.... > > The problem then is that the @ejb:persistent-field with '@jboss:create-table > "true"' *also* causes the field to be generated in the database. There's no > way around it with all of the four pieces... create-table, CMP, dataobjects > and strutsforms because of the common reliance on @ejb:persistent-field. > > Or is there? > > The answer I'm gonna fly with for now is to lose the @jboss:create-table when > I get closer to production and not worry about what the database looks like > in the mean time. > Vincent _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
