Re: Session Objects Approach
I found another con with detachable is that if you are constructing a complex object graph _before_ putting it in the database you would have to do something cleverer... e.g. only detach if already persisted? We just stuck with non-detachable models. Eelco Hillenius wrote: Does this approach have any significant improvement over the former? and what could be the cons Like Alex said, look at LoadableDetachableModel for instance. You don't have to discard right away; just do at at the end of the request. It's what detachable is for. Pro detaching: less memory consumption per session, and you can avoid lazy loading problems when you use e.g. Hibernate. Con: more database traffic (if you don't cache these objects) and cpu usage (though very very minimal). In general a pro is also that your objects are always fresh. A general con when working in forms can be that you have to persist changes right away or you'll lose them with the reload. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Just trying to be helpful. :-) Igor Vaynberg wrote: I think what you all are missing in this discussion is that ldms are mostly uss for read only data, not for forms. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
I found another con with detachable is that if you are constructing a complex object graph _before_ putting it in the database you would have to do something cleverer... e.g. only detach if already persisted? We just stuck with non-detachable models. But the solution to that might be easy: only use the detachable model on the top object of your complex graph, and let all other models use that model (opposed to the model object). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Does this approach have any significant improvement over the former? and what could be the cons Like Alex said, look at LoadableDetachableModel for instance. You don't have to discard right away; just do at at the end of the request. It's what detachable is for. Pro detaching: less memory consumption per session, and you can avoid lazy loading problems when you use e.g. Hibernate. Con: more database traffic (if you don't cache these objects) and cpu usage (though very very minimal). In general a pro is also that your objects are always fresh. A general con when working in forms can be that you have to persist changes right away or you'll lose them with the reload. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Take a look on LoadableDetachableModel..
Ayodeji Aladejebi wrote:
Basically there is an object like this, a common model
class User{
Long id;
String username;
String password;
String fullname;
...
List collections;
}
From most examples and basic approach, i see references to this Object in
the session
During user sign in, this object is loaded from database and stored in the
memory and then during authentication, this object is checked against Null
to know if a user is signed in or not and then if required, a getter in
the
session returns the reference.
Please correct me if I am wrong,
Now I thought,
Instead of keeping the object reference in the session after a sign in,
why
not just keep the ID (Long) and then during authentication, the code just
checks for Null or Zero
and then if the entire user object is required in any of the pages, The
USER ID is passed into the DAO which then loads the object and then
discarded immediately after use so that no references exists to it again
Does this approach have any significant improvement over the former? and
what could be the cons
Thanks
--
View this message in context:
http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13143236
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
