You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matthias Wessendorf <ma...@apache.org> on 2007/09/21 14:42:30 UTC
TRINIDAD-729
Hi guys,
I added a patch (and a comment) to TRINIDAD-729 (see [1]).
I am not sure if there is an issue with this fix/patch.
Do you mind to review it ?
Thanks!
Matthias
[1] https://issues.apache.org/jira/browse/TRINIDAD-729
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: TRINIDAD-729
Posted by Adam Winer <aw...@gmail.com>.
At the moment, this doesn't come up that commonly in the
Trinidad components. But it could, if:
- We had an autosuggest component
- We supported autosubmit on any keypress in an input component,
not just on tab-out
There's a separate queueing question that also comes up,
which is that currently, if you have nothing but autoSubmit fields,
and you change A, then B, then C, but we're still processing
A, you'd really like to join B+C in one submit, instead of separating
them into two. For that, we really need an event queue (in addition
to our request queue.) In theory, we could design the event
queue to address both problems (delivering two different
events together, collapsing duplicate events.)
-- Adam
On 9/21/07, Andrew Robinson <an...@gmail.com> wrote:
> Yes, thought crossed my mind as well for something like that.
>
> Perhaps a common type of JS queue could be made for this, as I would
> not be surprised if this functionality is revisited elsewhere.
> Something like a non-duplicate PPR list, when a new event is added,
> the previous is removed and each event has a timeout associated with
> it (fire after x millis).
>
> On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > true,
> >
> > perhaps we can include TRINIDAD-730 as well.
> >
> > Like, after 1000 ms start with the "loop" of increase / decrease and
> > inside the loop,
> > every 100 ms, do an update. Once the "loop" get's its time-out, fire
> > the change event, for the spinbox.
> >
> > does that make sense ?
> >
> > -M
> >
> > On 9/21/07, Andrew Robinson <an...@gmail.com> wrote:
> > > Is this a good idea?
> > >
> > > If the user wants to increase the counter 5 times, you would not want
> > > 5 ajax calls for every time they click the up arrow.
> > >
> > > -Andrew
> > >
> > > On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > Hi guys,
> > > >
> > > > I added a patch (and a comment) to TRINIDAD-729 (see [1]).
> > > > I am not sure if there is an issue with this fix/patch.
> > > > Do you mind to review it ?
> > > >
> > > > Thanks!
> > > > Matthias
> > > >
> > > > [1] https://issues.apache.org/jira/browse/TRINIDAD-729
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > further stuff:
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > mail: matzew-at-apache-dot-org
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > mail: matzew-at-apache-dot-org
> >
>
Re: TRINIDAD-729
Posted by Andrew Robinson <an...@gmail.com>.
Yes, thought crossed my mind as well for something like that.
Perhaps a common type of JS queue could be made for this, as I would
not be surprised if this functionality is revisited elsewhere.
Something like a non-duplicate PPR list, when a new event is added,
the previous is removed and each event has a timeout associated with
it (fire after x millis).
On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> true,
>
> perhaps we can include TRINIDAD-730 as well.
>
> Like, after 1000 ms start with the "loop" of increase / decrease and
> inside the loop,
> every 100 ms, do an update. Once the "loop" get's its time-out, fire
> the change event, for the spinbox.
>
> does that make sense ?
>
> -M
>
> On 9/21/07, Andrew Robinson <an...@gmail.com> wrote:
> > Is this a good idea?
> >
> > If the user wants to increase the counter 5 times, you would not want
> > 5 ajax calls for every time they click the up arrow.
> >
> > -Andrew
> >
> > On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Hi guys,
> > >
> > > I added a patch (and a comment) to TRINIDAD-729 (see [1]).
> > > I am not sure if there is an issue with this fix/patch.
> > > Do you mind to review it ?
> > >
> > > Thanks!
> > > Matthias
> > >
> > > [1] https://issues.apache.org/jira/browse/TRINIDAD-729
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > mail: matzew-at-apache-dot-org
> > >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
>
Re: TRINIDAD-729
Posted by Matthias Wessendorf <ma...@apache.org>.
true,
perhaps we can include TRINIDAD-730 as well.
Like, after 1000 ms start with the "loop" of increase / decrease and
inside the loop,
every 100 ms, do an update. Once the "loop" get's its time-out, fire
the change event, for the spinbox.
does that make sense ?
-M
On 9/21/07, Andrew Robinson <an...@gmail.com> wrote:
> Is this a good idea?
>
> If the user wants to increase the counter 5 times, you would not want
> 5 ajax calls for every time they click the up arrow.
>
> -Andrew
>
> On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > Hi guys,
> >
> > I added a patch (and a comment) to TRINIDAD-729 (see [1]).
> > I am not sure if there is an issue with this fix/patch.
> > Do you mind to review it ?
> >
> > Thanks!
> > Matthias
> >
> > [1] https://issues.apache.org/jira/browse/TRINIDAD-729
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > mail: matzew-at-apache-dot-org
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: TRINIDAD-729
Posted by Adam Winer <aw...@gmail.com>.
I agree - in this case, you really want to add a delay with a JS window
timeout that keeps getting rescheduled (e.g., on every tick of the
counter, window.clearTimeout() if the timeout exists, then call
window.setTimeout()).
-- Adam
On 9/21/07, Andrew Robinson <an...@gmail.com> wrote:
> Is this a good idea?
>
> If the user wants to increase the counter 5 times, you would not want
> 5 ajax calls for every time they click the up arrow.
>
> -Andrew
>
> On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > Hi guys,
> >
> > I added a patch (and a comment) to TRINIDAD-729 (see [1]).
> > I am not sure if there is an issue with this fix/patch.
> > Do you mind to review it ?
> >
> > Thanks!
> > Matthias
> >
> > [1] https://issues.apache.org/jira/browse/TRINIDAD-729
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > mail: matzew-at-apache-dot-org
> >
>
Re: TRINIDAD-729
Posted by Andrew Robinson <an...@gmail.com>.
Is this a good idea?
If the user wants to increase the counter 5 times, you would not want
5 ajax calls for every time they click the up arrow.
-Andrew
On 9/21/07, Matthias Wessendorf <ma...@apache.org> wrote:
> Hi guys,
>
> I added a patch (and a comment) to TRINIDAD-729 (see [1]).
> I am not sure if there is an issue with this fix/patch.
> Do you mind to review it ?
>
> Thanks!
> Matthias
>
> [1] https://issues.apache.org/jira/browse/TRINIDAD-729
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
>