if you disable cookies it will be appended to every url.
if you use cookies after the first request jsessionid migrates from
urls to a cookie - so you see it on the first request of a new
session, and never again for the duration of that session.
-igor
On Jan 24, 2008 1:10 PM, mfs <[EMAIL PROTECTED]> wrote:
>
> makes sense...
>
> Just one more thing which i just noticed..not sure if it has got to with the
> mounting of urls, but in certain instances i seet he jsession="[id]"
> postfixed with the urls, but not for all pages, its just random..even at
> times it appears for one and at a different time it doesn't. Any idea ?
>
>
>
> igor.vaynberg wrote:
> >
> > On Jan 23, 2008 6:32 PM, mfs <[EMAIL PROTECTED]> wrote:
> >>
> >> Wouldn't the former approach have more overahead since it would first
> >> load
> >> the Contact (when the getmodelobject() is called) and than the deletion
> >> operation..
> >>
> >> The later one atleast just does the deletion in one call though based on
> >> its
> >> primary key..
> >
> > well, that all depends. if you are using something like hibernate or
> > something else that has a query cache then the chances of a query to
> > load the object are significantly reduced. also, how often do users
> > delete the object? so you are really optimizing a rare usecase...
> >
> > what you gain is that your UI code is not polluted with calls that
> > require you to load things. you simply have an IModel to deal with.
> >
> > -igor
> >
> >
> >>
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > 1) when the page is opened the second time there will not be N
> >> > selects, next time please confirm that it is indeed the case before
> >> > posting to this list. it is not the case because when the page is
> >> > opened the second time the items in dataview are discarded and
> >> > recreated in the exact same manner as when the page was opened the
> >> > first time...
> >> >
> >> > 2) why the detachable model is there:
> >> > in order to identify an entity in the database you use its primary
> >> > key. the contactdetachablemodel is like that primary key. lets assume
> >> > in your dataview.populateitem() you do
> >> >
> >> > item.add(new link("delete", item.getmodel()) { onclick() {
> >> > dao.delete(getmodelobject()); }});
> >> >
> >> > that link needs to be tied to the contact it needs to delete
> >> > somehow...how do you do that. well you can use the model like i did
> >> > above, or you can do
> >> >
> >> > populateitem(item item) {
> >> > Contact c=item.getModelObject();
> >> > item.add(new link("delete", new model(c.getid()) { onclick() {
> >> > dao.deletebypk(getmodelobject()); }});
> >> >
> >> > but this breaks encapsulation because you need to know what contact's
> >> > primary key is, it is much easier to deal with an imodel and not care.
> >> > also if you need to pass this contact down to a panel, that panel can
> >> > also just take an imodel and be able to retrieve that contact on
> >> > subsequent requests without having to know how to do that via a
> >> > primary key. makes sense?
> >> >
> >> > to sum up: the contactdetachablemodel is like an abstraction to a
> >> > primary key and a way to retrieve the contact by its primary key.
> >> >
> >> > -igor
> >> >
> >> > On Jan 23, 2008 3:29 AM, beam <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Hello everybody!
> >> >> There is a page PagingPage in Wicket Examples(repeater folder)
> >> >> And this page contain next code:
> >> >> DataView dataView = new DataView("pageable", new
> >> ContactDataProvider())
> >> >>
> >> >> ContactDataProvider implements method iterator:
> >> >>
> >> >> public Iterator iterator(int first, int count)
> >> >> {
> >> >> return getContactsDB().find(first, count, "firstName",
> >> >> true).iterator();
> >> >> }
> >> >> It returns List of Contacts.
> >> >>
> >> >> And there is next code:
> >> >> /**
> >> >> * wraps retrieved contact pojo with a wicket model
> >> >> *
> >> >> * @see
> >> >>
> >> org.apache.wicket.markup.repeater.data.IDataProvider#model(java.lang.Object)
> >> >> */
> >> >> public IModel model(Object object)
> >> >> {
> >> >> return new DetachableContactModel((Contact)object);
> >> >> }
> >> >> So why we need to wrap every item of this List to
> >> DetachableContactModel.
> >> >> When page open in a first time there will be only on SELECT request
> >> to
> >> >> Database(iterator(int first, int count) -> SELECT * FROM Contacts
> >> LIMIT
> >> >> first, count)). But when page will open in a second time there will be
> >> N
> >> >> SELECTs (where N == count) for every Contact object in
> >> >> DetachableContactModel because it calls method load().
> >> >>
> >> >> So I don't understand why wrap items(Contact in this example) to
> >> >> DetachableContactModel? One select to retrieve all Contact on the page
> >> >> better than N SELECTs, isn't it?
> >> >>
> >> >> P.S. Sorry for my bad english
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Confused-with-IDataProvider-tp15039652p15039652.html
> >> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> 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]
> >> >
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Confused-with-IDataProvider-tp15039652p15057496.html
> >>
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Confused-with-IDataProvider-tp15039652p15075078.html
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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]
