passing wicket models around is good. My point was that shouldn't a page
have : (Ideally)
1.) Either component as attributes
2.) Or Wicket Models as attributes, should we need to expose a getter from a
page, we could use final Model aWicketWrapperModel = new Model(); and then
setObject( ) on it ...
I meant, whats wrong IMHO is to use non wicket models (or i guess a VO or
TO) on pages and expose getter and setter); we could potentially use a
DataProvider (I use term DataProvider to mean DP that "provides" data to a
component (that could be a container, panel, page or whatever), this is
similar to whats there in Wicket already; and a DP we use (at our workplace)
is something like: DP<VOMODEL>). so at worst should be need to expose a
getter and setter for such a VO; we "could" use a DP and to pass the data
around. But we really shouldnt.
So a typical flow would be Page <--- DataProviderForModel<MODEL> <-- Biz
tier <--- DAO tier.
Is that the right thinking?
Rick
On Mon, Jul 28, 2008 at 8:48 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:
> whats wrong with passing models around?
>
> -igor
>
> On Mon, Jul 28, 2008 at 5:45 PM, Ricky <[EMAIL PROTECTED]> wrote:
> > 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
> > || ॐ ||
>
