I believe its not the right place to proceed with this issue now that i have
some more questions, so i am going to start a new thread.."when cookies are
disabled"
igor.vaynberg wrote:
>
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/Confused-with-IDataProvider-tp15039652p15078584.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]
