I'd agree on the use of the FBO in most cases, and as of SpringMVC v1.8 and and I believe 2.0, hidden fields are required in the page in order to be bound. There are of course exceptions to this pattern, e.g. if your domain object contains a large data field(s) unnecessary for the user to see, i.e. a blob/clob/image. In that case, working in HBM, AFAIK there are no better alternatives to what you're already doing.
In such cases, and maybe in your case, you can refactor your domain objects to move the system-maintained fields to an associated entity. In this case it can make sense to maintain a lightweight base domain object used for page views, and an aggregated object subclass for times when all data is required. Of course using an ORM this will require 2 mappings, but if you're using object versioning you won't encounter conflicts. I have used this pattern with success - note that you don't really want to introduce this into your domain model unless there is a real business argument for it - don't just do it for performance, it can become a slippery slope. Maybe someone more versed in HBM (or your ORM) than I will know a way to do optional field updating that won't require real design changes. Mike Horwitz wrote: > > On 22/02/2008, reddeagle9 <[EMAIL PROTECTED]> wrote: >> >> >> I am currently working on a project that has an existing DAO layer in >> place. >> One of the domain models has 20 attributes, but only 10 of these are >> editable via the web. The other 10 are set by back ground processes. >> >> My question to the group, is what strategy to people take for this. >> >> Currently I retrieve a record from the DB populate this object. >> >> I then use this object on my web form, but do not set hidden fields for >> values that are not editable. >> >> When I save, the object only has 10 fields set, the others are null. >> >> In my service layer before saving this object, I retrieve the existing >> one >> (in case updates have been made since user edited) and I manually copy >> the >> properties from the web version of the model to the dao model and save. >> >> While it works fine, I am just wondering whether this is the right >> approach >> or what do people generally do in this case? > > > In your controller you presumably override formBackingObject()? I am > assuming you return the object from the database in this case (i.e. you > embed the object id in the form using a hidden field). I have not tried > this, but Spring may just bind only the fields it finds in the form. If > not > the solution is to set the allowed fields in the binder using initBinder() > and use setAllowedFields() to list the fields allowed from the form. All > other values should be ignored. > > Mike > > Cheers >> -- >> View this message in context: >> http://www.nabble.com/Working-with-existing-domain-model-classes-in-spring-mvc-tp15631877s2369p15631877.html >> Sent from the AppFuse - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/Working-with-existing-domain-model-classes-in-spring-mvc-tp15631877s2369p15634459.html Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
