sure you can have a constructor with a signature (IModel<Group>,
IModel<User>) at runtime it will just look like (IModel,IModel) which
is a perfectly good signature.
-igor
On Thu, Jul 24, 2008 at 4:50 AM, John <[EMAIL PROTECTED]> wrote:
> hi Igor,
>
> i do have a detachable Group model so am now passing that into my
> CreateUser page - thank you
>
> that is a very interesting point regarding serialization... thank you
> for mentioning it! i will have to bear that in mind.
>
> as i understand generics, the generic identity is lost at run time so
> you cannot have two constructors accepting different IModels like
> IModel<Group> and IModel<User>. is there an obvious way around this
> that i have not spotted? my CreateUser page is also an edit page...
> as the code is exactly the same i am reusing it... but a create would
> pass a IModel<Group> but an edit would pass IModel<User>, but it
> cannot!!! i have passed in the user id instead, and am loading it
> manually inside the page even though i already have the User object
> inside a detachable model when i make the Link to the edit page. does
> this sound correct?
>
> hi Thomas,
>
> those are good rules! i have written many pages with ids being used
> in Links, so for easy access to the object inside the model, i have
> creating final references to the model object at the start of the
> constructor... and then just calling myobject.getId() where needed. i
> am concerned that this might break your second rule, as the object
> inside the model may not be the same i think?
>
> i have read that for example new Label(myObject.getName()) is bad
> because the Label will be fixed as the name when the page was first
> constructed, but it will not change if the name changes but the page
> is redisplayed. however i have a gap in my understanding regrding
> redisplay of the page...
>
> when does a page get redisplayed? a page that displays a School
> information can not be re used for a different School i think as the
> IModel<School> or School id will be passed to the page constructor.
> so it will only be displayed for the one School... does that mean
> that the School object that is inside the model on the page will
> always be the same or will that object change when the model is
> detached and reattached? so my final reference to the School object
> is a bad bad thing?
>
> also... when you view a different School does the first page still
> exist? i can see the first page can not be reused if i click a link
> to view the first School that is passing a IModel<School> into the
> constructor, but if I pass the School id number via a PageParameters
> will Wicket reuse a page if the PageParameters match?
>
> john...
>
>
>
> On Tue, Jul 22, 2008 at 9:41 AM, Thomas Mäder <[EMAIL PROTECTED]> wrote:
>> I have three rules for directly referencing objects from pages
>>
>> 1) It's serializable
>> 2) The valueis not going to change from the time I construct the page
>> to when I use the object
>> 3) It doesn't matter if I get a copy of the object (because of
>> deserialization).
>>
>> 2 & 3 can be summarized as the object being a value object
>>
>> Thomas
>>
>>
>> On Mon, Jul 21, 2008 at 6:25 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>>> 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]
