Not all values will be overwritten, and if you don't check for
concurrent updates (your users will try to modify the same object at
the same time!) you are in for some hefty support calls.

And if you disable a field, its value will not be part of the form
processing, also something to take into consideration.

Hibernate and JPA use optimistic locking by introducing a version
field. The first person to save the update 'wins'. The second will not
be able to update (the version has been upped, effectively changing
the logical key for the object, so the update will not find the
record). This version can be stored in your model or even in your form
[1].

Also, how are you going to resolve the relations? Person -> Address?
Are you going to create those as well?

I think your approach is novel, but may need some thorough thinking.

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

Reply via email to