I think is unique enough. It describes
what it does, and it matches the naming pattern that we've used for
other ActionListeners (verb ActionListener). Another possiblity
would be "resetUIDataFirstActionListener", but I think that's too
restrictive as we may decide to reset other UIData attrib
<[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> Hi Paul and Mike,
>> >> >>
>> >> >> Based upon your comments I was able to get the dataTable reset
>> >> >> expl
; >> >> >actionListener="#{searchPageBean.resetDataScroller}">
>> >> >> >
>> >> >> >
>> >> >> > The real trick is that we don't want to have to do this by
>> >> referencing
>&g
example.
>> >> >
>> >> > I suspect that would need to be an
>> >> > ActionListener component.
>> >> >
>> >> > On 2/27/07, Beelen, Marco <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >
d need to be an
>> >> > ActionListener component.
>> >> >
>> >> > On 2/27/07, Beelen, Marco <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> Hi Paul and Mi
et, when it isn't
>> wanted.
>> >>
>> >> Maybe the updateActionListener can provide some inspiration about
>> this.
>> >>
>> >> How about something like:
>> >>
>> >> > >> value="Submit Query"
e
>> >> 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:
&g
o change the property to the
>> specified value after the INVOKE_APPLICATION-phase.
>>
>> An slightly different approach would be something like this:
>>
>> > value="Submit Query"
>> action="#{searchPageBean.search}"
>>
&
ase.
>>
>> An slightly different approach would be something like this:
>>
>> > value="Submit Query"
>> action="#{searchPageBean.search}"
>>
>> actionListener="#{searchPageBean.resetDataScroller}">
>>
&
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 200
efull 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
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
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
suspec
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 backwa
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
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 unflex
16 matches
Mail list logo
