Hi Martin,
do you mean this one ?
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/tagdoc/core/resetActionListener.html
It's a declarative way to reset the form bean, not to perform reset of
UIData :(
regards,
paul
Martin Marinschek schrieb:
> I don't know if it serves the same cause, but I have recently seen a
> "resetActionListener" in Trinidad.
>
> regards,
>
> Martin
>
> On 2/28/07, Paul Iov <[EMAIL PROTECTED]> wrote:
>> Hello Mike.
>>
>> Well, the <t:uiDataReset> seems really to be a lowest common denominator
>> for a while. If no other suggestion will be given I'll try to implement
>> such component, presumably this or next week. I think, it should be
>> something like:
>>
>> <t:uiDataReset
>> for="id of UIData"
>> resetTo="int or value-binding" optional, 0 by default, argument to
>> be used in setFirst(), if provided
>> cancel="boolean or value-binding" optional, false by default, if
>> evaluates to true no setFirst() performed
>> />
>> Any suggestions/comments are still welcome.
>>
>> I'm pretty new to MyFaces project, so may be I'll be needing then some
>> help as for contributing it (to sandbox?) etc. Any way, many thanks Mike
>> for your patience and advices about mailing list/JIRA. :)
>>
>> regards,
>> paul
>>
>> Mike Kienenberger schrieb:
>> > I guess it depends if we're looking at a present or a future fix.
>> >
>> > - You won't be able to make changes to UIData until at least JSF 2.0.
>> >
>> > - If you only change the Tomahawk UIData base, you'll still be unable
>> > to handle ui:repeat, jenia4faces data tables, and other 3rd party
>> > components.
>> >
>> > The other problem is that UIData doesn't know when the data is dirty.
>> > That information is provided by the backing bean providing the
>> > DataModel to the UIData. I could be wrong about this, but that's my
>> > understanding. As an application programmer, I know when I've put
>> > the UIData into a dirty state (ie, I performed a new search and
>> > changed the backing list). Thus, it's my responsibility to determine
>> > how to fix it (ie, setFirst(0)).
>> >
>> > Yes, if there's a complex value needed for setFirst()'s argument, then
>> > you'll have to compute it in a backing bean. But that's true of any
>> > complex situation.
>> >
>> > For most use cases, all that is needed is the following. Seems pretty
>> > easy.
>> >
>> > <h:commandButton
>> > value="Submit Query"
>> > action="#{searchPageBean.search}">
>> > <t:uiDataReset for="id of uiData">
>> > </h:commandButton>
>> >
>> >
>> > On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:
>> >> Well, I've listed of course the UIData descendant(s) from core JSF
>> >> implementation, since I've think about general solution at this
>> level :)
>> >> Sure, all of t: data components relay on this class, but if there
>> is a
>> >> solution at this level, all of them get this solution automatically.
>> >> I've thinking first about something like public boolean isDataDirty()
>> >> property: UIData tracks changes in DataModel and informs about
>> this all
>> >> 'interested' components, so they can recalculate page number, perform
>> >> some reset etc. But then I've realized that this would be not
>> especial
>> >> useful, if no such components are attached to the instance of UIData.
>> >> There is no way to prevent UIData to be rendered in incorrect state
>> >> after DataModel change, if UIData not tracks this itself.
>> >>
>> >> From programmer's point of view (I mean not only programmer of
>> custom
>> >> components such DataScroller, but of backing bean too) there is
>> one more
>> >> reason to ask for some general solution at UIData level. After
>> changing
>> >> DataModel I have to decide in my code, weather UIData.setFirst()
>> should
>> >> be called (probably, with which argument too, because calling
>> every time
>> >> just setFirst(0) is quick'n'dirty solution and an optional
>> parameter, to
>> >> be used in setFirst(), must be also in some way calculable). Since
>> this
>> >> decision depends on implementation of used UIData (h:dataTable or
>> >> t:dataTable or ...), I have to reference all of this classes and to
>> >> check: IF (a instanceof h:dataTable) ELSE IF(a instanceof
>> t:dataTable)
>> >> etc. because I have to know weather the actually UIData.getFirst()
>> >> stored in component's state is valid. It would be just a nice help
>> from
>> >> framework to provide i.e. IPageableData interface to make this
>> decision
>> >> easy. I have then to check: IF (a implements IPageableData) -> I
>> have
>> >> to respect getFirst() as well as i.e. getRowsPerPage(), ELSE -> I
>> have
>> >> to do with h:dataTable or even some non-pageable list and must to
>> call
>> >> setFirst(0) only. (It's just a suggestion, how the framework can
>> help to
>> >> keep business logic away from presentation level.)
>> >>
>> >> It would be pretty easy to implement <t:resetUIData for=""> even
>> with an
>> >> optional parameter to be used as setFirst() argument. The only
>> question
>> >> is, how such parameter can be calculated 'externally'. Another one:
>> >> what, if my action hasn't done any changes in DataModel (how can
>> it then
>> >> ask <t:resetUIData> not to call setFirst()) ?
>> >>
>> >>
>> >>
>> >> Mike Kienenberger schrieb:
>> >> > There's only two ways UIData can change. Either initiated in java
>> >> > code or initiated in page code. If it's in java code, then the
>> >> > programmer will have to call setFirst() manually. Only the
>> >> > programmer/page designer knows whether a change to the model should
>> >> > reflect a change in the displayed data, and what that change should
>> >> > be.
>> >> >
>> >> > If it's in page code, then we want to have an actionListener do
>> this
>> >> > without writing java code. I think your argument that the
>> component
>> >> > should be <t:resetUIData for="id of dataTable"/> rather than
>> >> > <t:resetDataScroller> is a good one. It probably makes sense
>> to have
>> >> > an optional value that can be set as the setFirst() argument.
>> >> >
>> >> > As for implementations of UIData, you're being too limiting.
>> So far,
>> >> > we've seen h:dataTable, t:dataTable, t:dataList, t:columns,
>> >> > t:newspaperTable, and ui:repeat. This is unlikely to be an
>> >> > exhaustive list, but is simply the ones I've come across myself.
>> >> >
>> >> > On 2/27/07, Paul Iov <[EMAIL PROTECTED]> wrote:
>> >> >> I'm thinking about some completely different approach. Let's
>> identify
>> >> >> the problem first. IMHO, the problem is not only the DataScroller,
>> >> >> displaying in incorrect state, but UIData, that stay in incorrect
>> >> state,
>> >> >> if underlying DataModel has been changed! What if one use no
>> >> >> DataScroller at all but set FirstRow of UIData somehow else? Let's
>> >> say
>> >> >> DataModel has 10 rows, and the FirstRow is set to 6 with 5 rows
>> per
>> >> >> page. Then some action changes the DataModel, and the new
>> >> 'version' has
>> >> >> only 5 rows. If no validation error occures, UIData restores it's
>> >> >> state... and the user is at page 2, that properly exists no more
>> >> :) The
>> >> >> scroller just reflects this situation, but is not a root of
>> problem
>> >> >> itself.
>> >> >>
>> >> >> I totally agree with Mike about that this issue is generally
>> UIData
>> >> >> related and should be discussed first. That's exactly what I mean
>> >> >> saying, this problem needs a solution, not a workaround. The
>> >> 'scroller
>> >> >> approach' is anyway a workaround, however it's better than
>> >> nothing. I'm
>> >> >> just going to add this feature to ajaxDataScroller, I'm using
>> due to
>> >> >> ajax incompatibility of t:dataScroller. (The idea is to store
>> >> RowCount
>> >> >> of underlying UIData in component state and to perform then
>> >> setFirst(0)
>> >> >> every time when the RowCount has been changed, directly in
>> >> dataScroller.
>> >> >> It's not exactly correct, since 1) the only task data scroller
>> should
>> >> >> really accomplish is to change first row pointer in UIData on user
>> >> >> input, not automaticly, 2) not only changing of RowCount can cause
>> >> >> incorrect state of scroller, but [item per page] in some UIData
>> >> >> descendant like t:dataTable too. )
>> >> >>
>> >> >> I'm not sure if linking data scroller or UIData to a backing
>> bean (to
>> >> >> let custom code decide, whether UIData should be reset?) makes any
>> >> sense
>> >> >> too because if row count of underlying DataModel has been changed
>> >> >> (generally, if DataModel has been SOME WAY changed), the current
>> >> page as
>> >> >> well as other 'current' things may become invalid and such
>> situation
>> >> >> should be handled at lowest possible level. It seems to me that
>> the
>> >> >> UIData itself stay the right place to solve this problem
>> >> (HtmlDataTable
>> >> >> is the only one known descendant of UIData and the data scroller
>> >> expects
>> >> >> an instance of UIData.) IMHO the 'right way' would be to supply
>> >> >> appropriative behavior directly in UIData.
>> >> >>
>> >> >> Probably some kind of extra components such as
>> <t:dataScrollerReset
>> >> >> for="..."> is the better way to preserve flexibility, but then it
>> >> should
>> >> >> be generally <t:resetUIData for="id of dataTable" ... /> :)
>> >> >>
>> >> >> Some other question to Mike. You have just closed MYFACES-1545. I
>> >> think,
>> >> >> it's something very similar to MYFACES-1532, I've created
>> >> 13.02.2007. I
>> >> >> have asked about this in both of DEV and USERS lists, but
>> nobody has
>> >> >> answered, so I'm still not sure, whether it's really a bug, or
>> just a
>> >> >> feature. (There are some other related issues too, however they
>> >> aren't
>> >> >> linked to this one.) Would you please confirm this or close 1532
>> >> too?
>> >> >>
>> >> >> regards,
>> >> >> paul
>> >> >>
>> >> >> Mike Kienenberger schrieb:
>> >> >> > 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.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>>
------------------------------------------------------------------------------
>>
>> >>
>> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
