Rails spinoffs - Aug 2005 - Observing changes to a text field

I''ve noticed that using several TimedObservers (prototype.js) on a page
to watch for changes to text fields (haven''t tried forms) can have a 
non-negligible effect on the CPU cycles used by the browser process. 
Nothing dramatic, to be sure, but unnecessary.

Autocompleter.Base (controls.js) follows a smarter strategy to watch for 
changes. Currently this functionality is tied to autocompletion, but 
something more general could be extracted to a superclass, say 
Abstract.FieldObserver or something. 

Right now I have too many open construction sites, but in a few weeks 
I''d happily supply a patch (unless Thomas opposes the idea or has done 
it himself by then).

Michael

-- 
Michael Schuerig                  Airtight arguments have
mailto:michael@schuerig.de        vacuous conclusions.
http://www.schuerig.de/michael/   --A.O. Rorty, Explaining Emotions

On 22/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> I''ve noticed that using several TimedObservers (prototype.js) on a
page
> to watch for changes to text fields (haven''t tried forms) can have
a
> non-negligible effect on the CPU cycles used by the browser process.
> Autocompleter.Base (controls.js) follows a smarter strategy to watch for
> changes.
One has to be careful when changing TimedOberver. The current
implementation  with setIntervall permanently monitors the field,
whereas Autocompleter.Base only does the monitoring when the field has
focus. So this would change the way TimedObserver works, and people
might depend on it (e.g. to also react on value changes done by
script).

So I vote for leaving Form.Element.Observer the way it is and adding
Form.Element.UserinputObserver and Abstract.UserinputObserver with the
setTimeout Autocompleter implementation as its and Autocompleter.Bases
parent.


Bye,
  Martin
.

On Monday 22 August 2005 23:04, Martin Bialasinski
wrote:
> On 22/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> > I''ve noticed that using several TimedObservers (prototype.js)
on a
> > page to watch for changes to text fields (haven''t tried
forms) can
> > have a non-negligible effect on the CPU cycles used by the browser
> > process.
> >
> > Autocompleter.Base (controls.js) follows a smarter strategy to
> > watch for changes.
>
> One has to be careful when changing TimedOberver. The current
> implementation  with setIntervall permanently monitors the field,
> whereas Autocompleter.Base only does the monitoring when the field
> has focus. So this would change the way TimedObserver works, and
> people might depend on it (e.g. to also react on value changes done
> by script).
No, I''m sorry, if I haven''t made this clear enough. I
don''t advocate
replacing TimedObserver with anything else. It is fine as is. But there 
are cases where it is not needed. I''m currently using it in my own 
JavaScript code and these are exactly cases where it is not needed. I 
don''t want to copy & change Thomas''s code to suit my
needs, instead,
I''d prefer to have generally useful functionality extracted into an 
abstract base class.
> So I vote for leaving Form.Element.Observer the way it is and adding
> Form.Element.UserinputObserver and Abstract.UserinputObserver with
> the setTimeout Autocompleter implementation as its and
> Autocompleter.Bases parent.
Did you miss Abstract.EventObserver and Form.Element.EventObserver, 
too? ;-) I only learned of them when I wrote my previous message and 
looked at prototype.js again. Originally I thought of abstracting out 
the observer code from Autocompleter into an independend superclass. 
But now it looks attractive to integrate it with 
Abstract.EventObserver. Currently, that class observes the change event 
on text fields (and similar), with an option it could be switched to 
observe keypress events. Additionally, these events (or keycodes?) 
would have to be passed to an overriden method of derived classes.

Michael

-- 
Michael Schuerig                       Face reality and stare it down
mailto:michael@schuerig.de        --Jethro Tull, Silver River Turning
http://www.schuerig.de/michael/

On 23/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> Did you miss Abstract.EventObserver and Form.Element.EventObserver,
> too? ;-)
Thinking about it some more, we have three cases:

1) Periodically trigger an action -> Abstract.TimedObserver
2) Action triggered by an event -> Abstract.EventObserver
3) Event schedules an action (= delayed action). If another event
occures before the action has run, it is rescheduled (=delayed
further) -> Autocompleter.Base

Case 3) has two components: a) The event as the wake-up call to react
on (like Abstract.EventObserver), and b) the delayed action.

Maybe making a Abstract.EventWithDelayedActionObserver based on
AbstractEventObserver?
Autocompleter is then based on this as well as the text field observer
from your initial post.

Bye,
  Martin

On Tuesday 23 August 2005 15:53, Martin Bialasinski
wrote:
> On 23/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> > Did you miss Abstract.EventObserver and Form.Element.EventObserver,
> > too? ;-)
>
> Thinking about it some more, we have three cases:
>
> 1) Periodically trigger an action -> Abstract.TimedObserver
> 2) Action triggered by an event -> Abstract.EventObserver
> 3) Event schedules an action (= delayed action). If another event
> occures before the action has run, it is rescheduled (=delayed
> further) -> Autocompleter.Base
>
> Case 3) has two components: a) The event as the wake-up call to react
> on (like Abstract.EventObserver), and b) the delayed action.
Yes, those are the cases. Possibly 2) and 3) can be combined and 
differentiated by an option...
> Maybe making a Abstract.EventWithDelayedActionObserver based on
> AbstractEventObserver?
...with a clearer naming. "Delayed action" obscures the intention. 
What''s special about 3) is that it is not so much the user event itself
that is of importance, but rather the ("synthetic") event that a new 
stable state has been reached. (Is 3) the first derivative of 2)?) Thus 
in both cases there''s an event that''s observed.

Michael

-- 
Michael Schuerig                          Thinking is trying to make up
mailto:michael@schuerig.de                for a gap in one''s education.
http://www.schuerig.de/michael/                          --Gilbert Ryle

On 23/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> ...with a clearer naming.
I could come up with something good :-) Any suggestion?
> (Is 3) the first derivative of 2)?) Thus
> in both cases there''s an event that''s observed.
Another posibility would be to use a specialisation of EventObserver
as the base for the Autocompleter. And a new DelayedAction class with
.schedule(), cancel(), .postpone(). General reaction on the original
event is done like in EventObserver, but additionally, the new
Abstract class manipulates an instance of this DelayedAction class.

Just thought of it because a DelayedAction (= setTimeout on steroids)
might be useful for other things as well.

Bye,
  Martin

On Wednesday 24 August 2005 00:34, Martin Bialasinski
wrote:
> On 23/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> > ...with a clearer naming.
>
> I could come up with something good :-) Any suggestion?
Not right now. My mind is flooded with other stuff. Anyway, have I 
talked you into writing a patch ;-)

Michael

-- 
Michael Schuerig                         Those people who smile a lot
mailto:michael@schuerig.de                             Watch the eyes
http://www.schuerig.de/michael/    --Ani DiFranco, Outta Me, Onto You

On 24/08/05, Michael Schuerig <michael@schuerig.de>
wrote:
> On Wednesday 24 August 2005 00:34, Martin Bialasinski wrote:
> > On 23/08/05, Michael Schuerig <michael@schuerig.de> wrote:
> > > ...with a clearer naming.
> >
> > I could come up with something good :-) Any suggestion?
> 
> Not right now. My mind is flooded with other stuff. Anyway, have I
> talked you into writing a patch ;-)
No :-) Besides, it is not even clear in which way things should be
changed so that they are acceptes. And I do not even use the
Autocompleter stuff, so I am not in the best position to make any
changes. I simply do not currently have time to set up new things.

Bye,
Martin

Has anybody been successful at using insertion:after to append a row onto a 
table? IE doesn''t seem to like it very much. I have my table set up 
something like the following where I am trying to appenda a row to the tbody 
element:

<table>
<thead>
<tr>
<th>
some data heading
</th>
</tr>
</thead> 
<tbody id="dataBlock">
<tr id="someData_1">
<td>
some data
</td>
</tr>
<tr id="someData_2">
<td>
some data
</td>
</tr>
<tr id="someData_3">
<td>
some data
</td>
</tr>
</tbody>
</table>

Any help our suggestions would be appreciated as I know this is possible.

-- 
Eric Fleming
efleming@gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050825/21017207/attachment-0001.html