May be i am reading too much into this, but i thought the idea was that
Wicket components deal with Wicket models that in turn deal with Customer
(User / Application) models (or VO or anything like that).
Because to me, if we use Application / Non wicket models on components or
pass them around like that, it just says that we are short circuiting to
allow for components to directly deal with our application specific models
instead of Wicket models. Am i incorrect in my understanding?
On Thu, Jul 24, 2008 at 11:45 AM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:
> 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]
>
>
--
Regards
Vyas, Anirudh
|| ॐ ||
