2 Minor Enhancements to PeriodicalUpdater

On Jan 21, 2008 9:27 PM, Justin Perkins
<justinperkinsgmail.com> wrote:
> 1) Delayed start of the Ajax requests
> 2) Max frequency, when using decay
>
> I use Ajax.PeriodicalUpdater a lot, but two things that
I've never liked is
> the immediate start of the Ajax request and the
infinite growth of the
> frequency that the decay option introduces.
>
> I noticed that the infinite growth problem was tackled
with a patch quite a
> while ago, but it never made it into the final release
for one reason or
> another (maybe because it turned into a debate about
variable names). Here
> is the ticket:  http://dev.rub
yonrails.org/ticket/8184
>
> Here is are two small wrap methods I use to enhance the
current version of
> Prototype's Ajax.PeriodicalUpdater (1.6.0.1):
> http://pastie.textm
ate.org/141709
>
> The code that precedes the call to updateComplete() is
admittedly
> convoluted, but it was the best I could do without
overwriting the entire
> method.

What about

  if (this.options.decay) this.decay =
Math.max(this.options.maxFrequency || -Infinity,
this.options.maxFrequency / this.frequency /
this.options.decay);

Gotta love Infinity 
(haven't tested it, but my mind tells me it should work)

> You may have seen my previous thread asking about using
delay() in
> conjunction with apply(), which I want to use in the
wrapped start() method.
> Since Ajax.PeriodicalUpdater#start () accepts no
arguments, it's not really
> needed, but I'm still curious about that one.
>
> Is this list a good medium to discuss this sort of
thing or should I just be
> submitting tested patches and hoping they find there
way into a future
> release?

I would discuss these sort of things in prototype-core

Best,
-Nicolas

> -justin
>  >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffsgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=
en
-~----------~----~----~----~------~----~------~--~---

On Jan 21, 2008 10:06 PM, Nicolás Sanguinetti
<godfocagmail.com> wrote:
> On Jan 21, 2008 9:27 PM, Justin Perkins
<justinperkinsgmail.com> wrote:
> > 1) Delayed start of the Ajax requests
> > 2) Max frequency, when using decay
> >
> > I use Ajax.PeriodicalUpdater a lot, but two things
that I've never liked is
> > the immediate start of the Ajax request and the
infinite growth of the
> > frequency that the decay option introduces.
> >
> > I noticed that the infinite growth problem was
tackled with a patch quite a
> > while ago, but it never made it into the final
release for one reason or
> > another (maybe because it turned into a debate
about variable names). Here
> > is the ticket:  http://dev.rub
yonrails.org/ticket/8184
> >
> > Here is are two small wrap methods I use to
enhance the current version of
> > Prototype's Ajax.PeriodicalUpdater (1.6.0.1):
> > http://pastie.textm
ate.org/141709
> >
> > The code that precedes the call to
updateComplete() is admittedly
> > convoluted, but it was the best I could do without
overwriting the entire
> > method.
>
> What about
>
>   if (this.options.decay) this.decay =
> Math.max(this.options.maxFrequency || -Infinity,
> this.options.maxFrequency / this.frequency /
this.options.decay);

DOH, just realized you still need to check for
this.o.maxFreq in the
'if', so no Infinity :(
But still using Math.max seems like a good solution to the
rest of your if.

(Math.max makes me think of nerdy post-apocalyptic movies)

-Nicolas

> Gotta love Infinity 
> (haven't tested it, but my mind tells me it should
work)
>
> > You may have seen my previous thread asking about
using delay() in
> > conjunction with apply(), which I want to use in
the wrapped start() method.
> > Since Ajax.PeriodicalUpdater#start () accepts no
arguments, it's not really
> > needed, but I'm still curious about that one.
> >
> > Is this list a good medium to discuss this sort of
thing or should I just be
> > submitting tested patches and hoping they find
there way into a future
> > release?
>
> I would discuss these sort of things in prototype-core
>
> Best,
> -Nicolas
>
>
> > -justin
> >  > >
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffsgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=
en
-~----------~----~----~----~------~----~------~--~---

Max frequency is indeed a long awaited feature.

As far as submitting patches, it's hard to consider those
without
accompanying unit tests, so it's definitely a good idea to
attach them
in the first place.

Best,
kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffsgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=
en
-~----------~----~----~----~------~----~------~--~---

> Is this list a good medium to discuss this sort of
thing or should I just be
> submitting tested patches and hoping they find there
way into a future
> release?

Hi,

You should bring development discussions to the core mailing
list
http:
//groups.google.com/group/prototype-core/.

They'll get a lot more attention there.

Best,

Tobie

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffsgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=
en
-~----------~----~----~----~------~----~------~--~---

On Jan 21, 2008 6:12 PM, Nicolás Sanguinetti <godfocagmail.com> wrote:
> (Math.max makes me think of nerdy post-apocalyptic
movies)

I think you just like geeking out, talking about negative
infinity and
maximum math integers ;)

I'm not sure that either of those would help my particular
situation,
as the max frequency I'm willing to allow is something
closer to 60
seconds.

In a nutshell, I want to be able to create a periodical
updater that
doesn't immediately start creating Ajax requests, and will
use an
initial frequency of 10 seconds, but will grow up to 60
seconds if the
response body stays the same.

My previous code snippet accomplishes both of these tasks,
but given
the relative low impact to the existing codebase and how
useful it
will probably be, I could see this as a valuable addition.

I will continue this conversion and others like it on the
core list,
as Tobie has suggested.

Thanks for your replies, have a great night.

-justin

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffsgooglegroups.com
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=
en
-~----------~----~----~----~------~----~------~--~---