Hi Martijn,
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.
Concurrent updates won't be common because most of the updated info will be
per user, and only one session could be opened per user. Anyway, in case
they do happen, I will use optimistic or pessimistic locking depending on
the particular scenario (most often pessimistic because concurrent editings
won't be frequent); and it's not always that I care about application-level
transactionality: you and me can start editing A, then you commit A', then I
commit A'', not serializable behaviour, but it would acceptable sometimes.
And if you disable a field, its value will not be part of the form
processing, also something to take into consideration.
Yep, in this case I would use LoadableDetachableModel to load the entity
every time. But it's not that often that my forms show just fragments of the
entire entity. I'm not proposing/asking for a one-size-fits-all solution,
just one that fits a use case like that described for the UserProfile.
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.
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
> Wicket-user@lists.sourceforge.net
> 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
Wicket-user@lists.sourceforge.net
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
