Actually, I think we'd want to reset it before the search action
executes in the general case. I'm pretty sure that's what happens
with the following. I suspect it doesn't really matter whether it's
before or after the action so long as it's before the rendering phase.
<h:commandButton
value="Submit Query"
action="#{searchPageBean.search}"
actionListener="#{searchPageBean.resetDataScroller}">
</h:commandButton>
The real trick is that we don't want to have to do this by referencing
a backing bean or by binding the UIData to a backing bean.
I think a better solution might be similar to what you proposed, though:
<h:commandButton
value="Submit Query"
action="#{searchPageBean.search}">
<t:dataScrollerReset for="id of dataScroller">
</h:commandButton>
I'm not completely sure what the mechanics of implementing
<t:dataScrollerReset for="id of dataScroller">
would be, but I would expect that someone could use
t:updateActionListener as an example.
I suspect that <t:dataScrollerReset> would need to be an
ActionListener component.
On 2/27/07, Beelen, Marco <[EMAIL PROTECTED]> wrote:
Hi Paul and Mike,
Based upon your comments I was able to get the dataTable reset explicitly by
coding it in the managed-bean performing the search. Thank you for the help!
After reading the issue and your comments I would like to give my ideas
about a possible solution. For me as an application developer it is
important to be in control about when the reset takes place. Especially when
there are multiple components on a page ( in a portal ) adding some
autoReset might cause the datatable to be reset, when it isn't wanted.
Maybe the updateActionListener can provide some inspiration about this.
How about something like:
<h:commandButton
value="Submit Query"
action="#{searchPageBean.search}"
actionListener="#{searchPageBean.resetDataScroller}">
<t:postProcessor property="#{idOfDataTable.first}" value="0" />
</h:commandButton>
The postProcessor would be responsible to change the property to the
specified value after the INVOKE_APPLICATION-phase.
An slightly different approach would be something like this:
<h:commandButton
value="Submit Query"
action="#{searchPageBean.search}"
actionListener="#{searchPageBean.resetDataScroller}">
<t:postProcessor action="#{idOfDataTable.reset}" />
</h:commandButton>
In this case the action of the postProcessor would be called after the
action of the commandButton has been executed.
This might prove usefull in other usecases as well. ( And if we have a
postProcessor, maybe a preProcessor would be usefull to ).
Just some thoughts.....
With kind regards,
Marco Beelen
-----Original Message-----
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: dinsdag 27 februari 2007 17:03
To: MyFaces Discussion
Subject: Re: Issue with the t:dataScroller
I mean that we know what the problem is, but not necessary what the
solution is :-)
Your solution will work for t:dataTable since we can change the source
code for that, but it won't work with other UIData components. It
sounds like a good start, though. Add it to the issue tracker. I
suspect the most flexible solution would be to trigger an action on
the DataScroller itself to reset its underlying UIData model.
Not sure how to do that short of binding the data scroller to a
backing bean, and then calling #{bean.dataScroller.reset}" from an
ActionListener or something similar.
On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:
> Hello Mike,
>
> what do you mean with 'placeholder for a better solution'? I think, the
> right way to solve this problem should be to improve the dataTable, i.e.
> with 'autoreset' property without needing to track any events in other
> components. This property cann be then false by default for backward
> compatibility (hovever, I can't imaginate any usecase for this behaviour)
> Any other solution will be IMHO some kind of workaround :)
>
> regards,
> paul
>
> Mike Kienenberger schrieb:
> > http://issues.apache.org/jira/browse/TOMAHAWK-548
> >
> > Includes the problem, the workaround, and a placeholder for a better
> > solution :-)
> >
> >
> > On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:
> >>
> >> It should be a dataTable issue. To workaround this, you must
> >> 'rewind' it
> >> manually with dataTable.setFirst(0); if some data was changed. You
> >> can do
> >> this in bean, that performs searching .
> >>
> >> 2 Adrian Mitev:
> >> Have you any informations on this dataTable issue? I've faced out,
that
> >> it's totally unflexible to fix the problem such way. I'm thinking about
> >> storing of 'last' record count in session or component state directly
in
> >> Scroller. The dataTable then cann be 'refreshed' automaticly, if record
> >> count has changed since last rendering :)
> >>
> >> regards,
> >> paul
> >>
> >> Beelen, Marco schrieb:
> >>
> >>
> >> Hello,
> >>
> >> In my application use a dataScroller on a t:dataTable for pagination
> >> and
> >> I'm happy with it's basic behaviour.
> >> But there is some case in which it doesn't act like I want it to and
> >> I hope
> >> that somebody can provided some infomation how to get around that.
> >>
> >> Here what I'm doing:
> >>
> >> I'm have a single page on which I have a form, in which the user can
> >> provided several search-criteria. After the user submit the form by
> >> pressing
> >> the search-button, the managed-bean retrieves a list of objects
> >> matching the
> >> criteria and hands that list over to another managed-bean, which is
> >> being
> >> referenced by the dataTable on the same page.
> >>
> >> ( Both beans are defined to be in the session-scope. )
> >>
> >> If the user scrolls to the end of the resulsset using the
> >> datascroller ( eq
> >> page 6 of 6 ) and then alters his search-criteria in such a way that
> >> less
> >> results are returned, that an empty list will be rendered and the
> >> message
> >> will be something like:
> >>
> >> Displaying page 6 of 3.
> >>
> >> I was wondering how I can make the datascoller be resetted on each new
> >> search-action?
> >>
> >> Any suggestions?
> >>
> >> With kind regards,
> >> Marco
> >>
------------------------------------------------------------------------------
> >>
> >> Notice: This e-mail message, together with any attachments, contains
> >> information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
> >> New Jersey, USA 08889), and/or its affiliates (which may be known
> >> outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
> >> and in Japan, as Banyu - direct contact information for affiliates is
> >> available at
http://www.merck.com/contact/contacts.html)
> >> that may be
> >> confidential, proprietary copyrighted and/or legally privileged. It is
> >> intended solely for the use of the individual or entity named on this
> >> message. If you are not the intended recipient, and have received this
> >> message in error, please notify us immediately by reply e-mail and then
> >> delete it from your system.
> >>
> >>
------------------------------------------------------------------------------
> >>
> >>
> >>
> >
>
>
------------------------------------------------------------------------------
Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD
and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html)
that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and then
delete it from your system.
------------------------------------------------------------------------------
