Also, how are you going to resolve the relations? Person -> Address? > Are you going to create those as well?Exactly. It's the thing most people do with spring-mvc I guess. There your request parameters are bound to fresh objects by default (although you could override formBackingObject() to change that). The associated objects are created in albis during construction of the main one, and so on recursively. Binding is then done up to arbitrary nesting levels.
To state this more precisely: relationships that are more of a component kind (and that will possibly be stored as dependants along the same table as the main entity) will be created "in blank" (of course, assuming you're in fact editing them from the form); combo-like stuff will be brought back from the database from id each time. I was doing the second using entity<-->id PropertyEditors in spring-mvc, still don't know how to get the same with wicket but I suppose it won't be hard. Regards,
Carlos Martijn > > [1] > http://martijndashorst.com/blog/2006/02/13/wicket-goodie-hibernate-versioned-form/ > > On 3/29/07, Carlos Pita <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > I'm migrating a spring-mvc project to wicket. In this project domain > objects > > are directly exposed to the ui (without DTOs in between). The objects > are > > validated using the spring bean validation framework (part of > > springmodules). This module creates a unique Validator (a spring > interface) > > from annotations given in the fields/properties of every validatable > object. > > Then you inject this global validator to your controllers (in the case > of > > spring-mvc) so they can validate their form/command (the bound > object). The > > result of validation is an Errors objects, with field errors and > global > > errors (more precisely, error codes to be resolved against a messages > > resource). It's pretty easy to map these errors from bean properties > to > > wicket component ids. This should be done inside onSubmit(), once the > object > > is bound (for example, using a CompoundPropertyModel). So, to recap: > domain > > objects directly exposed to the ui, Validator created from annotations > in > > validatable domain objects, domain objects bound by PropertyModels, > domain > > objects validated by injected validator during onSubmit. Up to this > point > > I'm pretty happy with the results, validation is almost trivial with > the > > annotations and the valang dsl, and I like it being inside the domain > > instead of tied to the ui components. > > > > One problem I have due to avoiding DTOs is that most of the time I > don't > > want to serialize my form models, because they are (often big) > entities with > > lazy loaded associations. So in principle I would use an > > LoadableDetachableModel to load the entity from the repository each > time the > > model is reattached. But suppose I'm updating a UserProfile. The first > time > > it would be ok to populate the model from the persistent profile to be > > > updated. But once the form is submitted there's no point in loading > the > > profile from the repository again because its properties would be > > overwritten from those coming from the form anyway. So I'm tempted to > > subclass AbstractDetachableModel so that it loads the profile from the > > repository upon creation, but instantiates a brand new profile to be > > populated from the form upon reattachment. Is there a better pattern > for > > this? Anyone has run into the same problem? > > > > Cheers, > > Carlos > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > > opinions on IT & business topics through brief surveys-and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Wicket-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > -- > Learn Wicket at ApacheCon Europe: http://apachecon.com > Join the wicket community at irc.freenode.net: ##wicket > Wicket 1.2.5 will keep your server alive. Download Wicket now! > http://wicketframework.org > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net 's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user >
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
