Thanks again. :)
-
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
Just a side question : when using a CompoundPropertyModel, is there a
way to dispose it later on the process or is it done automatically ?
For example, I use a Value Object (VO) to edit my user profile
(because there are some extra data to consider). Is this VO deleted
when the page onSubmit
Just a side question : when using a CompoundPropertyModel, is there a
way to dispose it later on the process or is it done automatically ?
It seems that in the current implementation you could call
setObject(null). Better is to provide a model as the target; for this
model you can implement any
My favorite way is to use the domain objects directly, but let updates
(to the database) always go through services/ daos and *not* have
transactions per request. I'll still use value objects every now and
then because sometimes it's just easier to work with a 'flat' object
that is focussed on a
the answer is simple: do not reattach objects. do not keep them across
requests unless you have a session that is open across requests. use a
detachable model that loads the objects at the beginning of the request and
discards them at the end. most times these are load-by-id operations which
are
I know I wasn't asked ;) but we had to revisit this question recently
in converting a Tapestry app over to Wicket. We started off trying to
use Hibernate objects directly for the usual reasons (avoid code
duplication, more elegant, etc.) but ran into a few problems.
A small but important
Thanks again for all these answers.
I just don't get right the last one :
They are also good for when you work with value objects ('thin'
representations of the your domain objects).
Could you be more explicit please ?
Thanks again
ZedroS
On 3/17/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 3/20/07, ZedroS Schwart [EMAIL PROTECTED] wrote:
Thanks again for all these answers.
I just don't get right the last one :
They are also good for when you work with value objects ('thin'
representations of the your domain objects).
Could you be more explicit please ?
That's was a really instructive post, thanks Eelco.
In fact I'm actually struggling with this kind of issue. I've model
objects and then on my presentation layer the data are quite often a
bit different, and thus I wonder which way is the best.
Igor had spoken about form beans, but then I've to
That's was a really instructive post, thanks Eelco.
In fact I'm actually struggling with this kind of issue. I've model
objects and then on my presentation layer the data are quite often a
bit different, and thus I wonder which way is the best.
Igor had spoken about form beans,
I think he
Thanks Jonathan for the tip.
I've now read on the wiki about it and this detachable compound
property model seems the best way to do (or even the Detachable
BoundCompoundPropertyModel !) .
I've just a question (a newbe one as usual lol) : how does wicket work
with non detachable models ? They're
Non-detachable models probably are not the best way to work
with a database. And since they can't be detached, your whole
model stays in the session the whole time, while the detachable
ones shrink to a few bytes (object header + id + transient slot)
when they are detached by Wicket after
Still, if you know what you are doing non-detachable models may be
appropriate. For example, I have used them for some slow-to-get database
query results. But I also wrote my own custom cached page invalidator to
make sure these results do not stay around for too long.
Regards,
Erik.
They are also good for when you work with value objects ('thin'
representations of the your domain objects).
Eelco
On 3/17/07, Erik van Oosten [EMAIL PROTECTED] wrote:
Still, if you know what you are doing non-detachable models may be
appropriate. For example, I have used them for some
you don't have to choose. you can wrap a compoundpropertymodel around a
detachablemodel and get both access convenience and detachability. wicket
models are much more flexible and powerful than most people realize at
first.
ZedroS Schwart wrote:
Thanks for your comment Igor, I really
Thanks for your comment Igor, I really appreciate.
Just some questions : do you use CompoundPropertyModel or the detachable one ?
For the form beans, the user profile page I'm working on really proves
you right. I was willing at first to avoid yet another bean but in
fact it seems indeed to be
Hi all
Among the questions I had, one of the core questions is the following
one : is the architecture I plan to use appropriate ? Just to give a
bit of insight, I'm new to Hibernate/Spring and Wicket (ouch !). lol
But I'm really motivated :) I would like to be sure I don't do huge
mistake in my
On 3/14/07, ZedroS Schwart [EMAIL PROTECTED] wrote:
When I have to change an object on the OnSubmit, I use the update
methods from my managers. What I fear here is to update some data
which have already been updated in between.
hibernate and jpa provide optimistic locking that guards against
18 matches
Mail list logo
