the easiest thing to do is to pass the imodel<group> into the second
page. i assume you already have a detachable group model that you are
using to list users, so just pass it to the next page.
in general keeping references to objects is safe for as long as the
objects them selves are valid. the problem with hibernate objects is
that although you have a reference that you can keep forever, the
object's lifecycle is not tied to that reference. the object is tied
to the session whose scope is usually a request, so the object itself
is only valid during the request, which is why you have to use
loadable detachable models.
if you had an object that is not tied to any kind of lifecycle you
could keep a reference indefinetely.
once you start talking about objects that live across pages you run
into another issue. wicket serializes each page individually. that
means if you pass a reference to an object from page A to page B, page
B will end up with a clone and change made to that object inside page
B will not be visible to page A. something to keep in mind. this is
not a problem for multiple references to an object within a page
because serialization will properly keep track of multiple references
to the same object.
clears things up?
-igor
On Mon, Jul 21, 2008 at 9:10 AM, John <[EMAIL PROTECTED]> wrote:
> hi, i am writing an application, but don't know how best to write it
> in wicket. i can see lots of different ways to approach my problem
> and would appreciate some direction as to which approach is the most
> appropiate. i have read the documentation in the wiki regarding
> models and understand the different page constructors but i am
> confused about how long the objects are safe to hold on to and which
> approach is best.
>
> here is some (pseudo)code for a page i need to write. my situation is
> i have one page which shows the details about a "Group" (collection of
> users), which has a link on it to create a new "User" and add it to
> the Group. (the CreateUser page has text boxes to set name ect and
> saves to the database on submit) my ViewGroupDetails page:
>
> // first decision = set the Group as a final variable before creating
> the link so it is still there in the onClick?
> final Group g = (Group)getModelObject();
> new Link("adduser") {
> public void onclick() {
> // or get Group from the page's model only when link clicked?
> Group g = (Group)ViewGroup.this.getModelObject();
> // second decision = pass the whole Group into the new page constructor?
> setResponsePage(new CreateUser(g));
> // or make the new User object here and pass it in?
> User u = new User();
> u.setGroup(g);
> setResponsePage(new CreateUser(u));
> // or pass in just the group id number?
> setResponsePage(new CreateUser(g.getId()));
> }
> }
>
> so the constructor of my CreateUser page will either take a Group and
> will create the User (as above), or take a Group's id number and load
> the Group from the database first, or take a User directly. an id
> number could be passed in by PageParameters or directly as an integer.
> an object could be passed bare or put inside a Model. i am not sure
> i am making any sense! i suppose my questions are...
>
> - how 'safe' is it to pass the Group directly to the new page constructor?
>
> - is it safe to create a final reference to an object and rely on that
> object being still there and intact by the time the link is clicked?
>
> - is it safe to getModelObject() to get the page's object at any time
> in the future?
>
> - i understand that the following is bad: new Label(group.getId())...
> better to use a model and load the id when needed... am i falling into
> the same trap with the final variables in the code above?
>
> john
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
