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 t
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 DefaultMuta
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 pa
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, Im
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 that
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 throu
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 mo
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 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 eff
