On 3/14/06, Igor Vaynberg <
[EMAIL PROTECTED]> wrote:
that should be fine for most cases.
the workflow would be:
when the form needs to render for the first time it will attach the detachable model and load your entity. individual components will pull their initial values from the entity
you submit the form - and there is an error
form will be refreshed based on previous entered input - not from your model
you submit the form and there are no errors - form is going to apply the values back into its model
your entity will be loaded - and values from individual form components applied via setters
hope this clarifies it some. we have tried to optimize our form workflow to make it as easy as possible.
-Igor
On 3/14/06, Vincent Jenks <[EMAIL PROTECTED] > wrote:Yep, it's the code duplication that seriously turns me off...and can make for some very tedious work if the object model should change.
I looked into Seam and IMO, it's a bit too intrusive on the session beans and really sort of blurs the line between your presentation and other app layers....though it obviously makes life easy. I just didn't care for it (compared to Wicket, which is quite elegant.)
If I'm using detached models and then merge them back into the persistence context after the form is submitted, I wouldn't have to worry about straggling sessions on my entities, would I? You'll have to forgive my ignorance, I just started using EJB3 about a week ago.On 3/14/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:On 3/14/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
> Oh I see, I hadn't noticed that, sorry. So it's similar to the "managed
> bean" concept in JSF? That was one of the things I *didn't* like about JSF,
> actually.
I would say it is more like the value object pattern, where you have a
- usually shallow - copy of a domain object just for the purpose of
passing parameters (input output) around in the view layer. The
disadvantage of that pattern is that you'll get quite some code
duplication. The advantage is that you'll never have to worry about
things like the integrity of your domain objects and whether or not
they have stale Hibernate/ EJB3 sessions attached. The difference with
JSF is that we don't force you in having any such bean, and that
Wicket doesn't manage the beans you provide.
Eelco
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
