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