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] > >
