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