The problem with #1 is, first its a bit ugly, second you discard every
persistent instance in each cycle (which is less efficient than #2 or
#3), third you lose the advantages of working passing POJO's between
pages, Like you would call 'new ProfilePage(person.getId())' instead of
'new
On 7/16/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
The problem with #1 is, first its a bit ugly,
Working with objects directly is always the nicest of course. In many
cases, where you just have to display some read-only information, you
don't really need to pass the model all the time
I don't think it is *that* less efficient. Attaching those objects
likely means refreshing them too, so the only gain you would have is
the creation of objects, and those few instances wouldn't even be
noticable, while the extra session size of #2 might be.
What I meant was mostly
Another case I just remembered where performance in #1 will be poor is
where you have a page containing a lot of panels, each of them needing
the model object or one of its associations. In #1 the object will be
loaded per panel, but in #2 or #3 you wont have any extra calls.
Iman
I don't think this is true if you create a hibernate session per http request
Juergen
On 7/16/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
Another case I just remembered where performance in #1 will be poor is
where you have a page containing a lot of panels, each of them needing
the model
Juergen Donnerstag wrote:
I don't think this is true if you create a hibernate session per http request
Juergen
When you pass the object id instead of the object to the panels, each
panel will retrieve the object independent of others. Maybe a cache will
help. But still it goes through
But that really depends on how you structure your models. If you use
models that do the loading once on attach, cache the results, and then
unload on detach, you wouldn't have the double loading if you share
the model. Instead of passing ids around, you pass around the model of
course. Besides
But you can pass the models too. It's not only a choice of either
passing in the object or their ids. And even if you would go through
the persistence layer, within the same transaction I think Hibernate
caches your objects too, so that would just be a very slight overhead.
Eelco
On 7/16/06,
yeah, you miss something. load-by-id is a cheap operation. first of all session.get(id) will return the cached object within the same request. and even if the first level cache misses(the session) the second level cache will most likely have the object where it is kept across requests.
so if you
Just looked into it a bit. The problem is that the TreeNode interfaces
really don't define enough behavior. Like getPreviousSibling,
getNextSibling, getPath, getLevel, preorderEnumeration and
getUserObject are all used in both Wicket's tree and Swing's Tree, and
they are only defined in
Thanks;)
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Johan Compagner
Sent: 14. juli 2006 15:07
To:
wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Playing
with models:)
Disableding/Enableing can
be done with pull (attributemodifiers on C/D
11 matches
Mail list logo
