myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Iov <p...@voller-ernst.de>
Subject Re: Issue with the t:dataScroller
Date Wed, 28 Feb 2007 14:09:50 GMT
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 <paul@voller-ernst.de> 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 <paul@voller-ernst.de> 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 <paul@voller-ernst.de> 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 <marco_beelen@merck.com> 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:mkienenb@gmail.com]
>> >> >> >> 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 <paul@voller-ernst.de> 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 <paul@voller-ernst.de>
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.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> 
>> ------------------------------------------------------------------------------ 
>>
>> >>
>> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>


Mime
View raw message