Hey,
so you've got a class CreateUser which is a factory that creates an Edit
Page? The name would be misleading i think. You could have something like
PageFactory<CONTAINER<MODEL>, CONTANER extends MarkupContainer, MODEL
extends IModel<?>> (i kept capture (?) just as an example) and throw in a
create method in there which is something like : createPage(final MODEL
model) { }.
But I am thinking that Wicket's idea was not to manage the life cycle of
objects to keep it simpler; otherwise its very easy to become Dependency
Injection type container to provide for things like above.
Just a thought, only Igor can verify that info, i could be plain wrong.
Regards,
Rick
On Tue, Jul 29, 2008 at 12:49 AM, Jeremy Thomerson <
[EMAIL PROTECTED]> wrote:
> As far as the constructor problem is concerned, I may not fully understand
> your problem, but what about static factory methods?
>
> CreateUser.createEditPage(IModel<Group>)
> CreateUser.createAddPage(IModel<User>)
>
> --
> Jeremy Thomerson
> http://www.wickettraining.com
>
> On Thu, Jul 24, 2008 at 6: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]
> >
> >
>
