Never ending poll when rendering periodical

Hello everyone,
Using a periodical with a high decay value sometimes causes a never ending poll mechanism. It seems that this depends on the type of brush being rendered, I can't find what i'm doing wrong though.
I'm having this problem when trying to render anything with a javascript event onXXX associated to it or simple form elements like basic checkboxes with nothing else (like in the example).
The scenario is something like this...
Trying to render a kind of progress bar or anything alike while a long running process is being executed server side, after the execution other things must be rendered..

The problem takes pleace where the text is in bold

MyComponent>>renderContentOn:html
   html div id:'div' with:'some content'.
   (html submitButton)
        onClick: (html evaluator callback: [:script |
                [(Delay forSeconds:10)"Simulate long running process".
                self setWorkFinished] fork
             
                (script element)
                   id: 'div';
                   render:[:r | r div
                       with: [:h |  h submitButton ]
                       waitForCondition: [self isWorkFinished]
                       thenRender:  [:h |  h checkbox]]"The problem takes place here!!!"
                ]);
        text: 'Spin'.
       
WATagBrush >> with: initialRenderBlock waitForCondition: aBlock thenRender: aRenderBlock
        self
            script: ((canvas periodical)
                  id: (self attributes at: #id);
                  decay: 1000;
                  asynchronous: true;
                  evalScripts: true;
                  frequency: 1 seconds;
                  callback:
                        [:r |
                        aBlock value
                            ifFalse:[initialRenderBlock value: r.
                                     r hiddenInput text: r nextId    "This is to keep decay low...generates different responses"]
                            ifTrue: [aRenderBlock value: r]]);
            with: initialRenderBlock
           
When rendering simple things like this ones, everything works just fine and the poll mechanism stops after the long running process has finished (as expected)
         <li>h text:'something..'
         <li>h radiobutton
         <li>h submitButton
         
But when trying to render anything more complex, after the long running process has finished, the poll mechanism is still alive and posts are sent to the server every 1 second (as stated in the frequency parameter of the periodical)
         <li>h checkbox
         <li>h submitButton onClick:(h evaluator)

I'm struggling with this for a while now and i can't solve it.. it's very frustrating...
any ideas?

help will be appreciated.
Thanks a lot,

 Leandro

i'm currently using
        VisualWorks NonCommercial, 7.5
        Seaside version 2.7b1.1
        Scriptaculous 2.6-mb.8

> Using a periodical with a high decay value sometimes causes a never ending
> poll mechanism. It seems that this depends on the type of brush being
> rendered, I can't find what i'm doing wrong though.

A periodical updater does never stop, unless you tell it to do so or a
full page refresh happens.

http://www.prototypejs.org/api/ajax/periodicalUpdater

> The problem takes pleace where the text is in bold

Most people use plain text mail clients only.

> MyComponent>>renderContentOn:html
>    html div id:'div' with:'some content'.

There seems to be a semicolon missing.

>    (html submitButton)
>         onClick: (html evaluator callback: [:script |
>                 [(Delay forSeconds:10)"Simulate long running process".

At least in Squeak you have to send #wait to the delay to actually start it.

>                   id: (self attributes at: #id);

You should use #ensureId instead.

>                   decay: 1000;

I don't see why you use a decay, because the HTML always changes when
you are rendering a link or form element. A decay of 1000 doesn't make
much sense, that's far too big. Reasonable values are something
between 1 and 2.

>                   asynchronous: true;

This is not necessary, as it is the default.

>                   evalScripts: true;

You only need this one if you are on an old version of Scriptaculous.

> When rendering simple things like this ones, everything works just fine and
> the poll mechanism stops after the long running process has finished (as
> expected)
>          <li>h text:'something..'
>          <li>h radiobutton
>          <li>h submitButton

Actually, it should never stop. It should go on forever.

Have a look at the code of this simple stop watch example. To stop the
timer it is required to call the method 'stop'. In my version of
Scriptaculous this method is oddly missing, so I directly call it. It
is essential that you assign your updater to a global variable, else
you are unable to stop it again.

renderContentOn: html
        html div id: 'time'.
        html submitButton
                onClick: (html periodical
                        id: 'time';
                        frequency: 1 second;
                        assignTo: 'periodical';
                        callback: [ :r | r render: (DateAndTime now - (start ifNil: [ start
:= DateAndTime now ])) ]);
                text: 'Start'.
        html submitButton
                onClick: (html periodical
                        alias: 'periodical';
                        call: 'stop');
                text: 'Stop'

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote

A periodical updater does never stop, unless you tell it to do so or a
full page refresh happens.

http://www.prototypejs.org/api/ajax/periodicalUpdater

That's the reason for which I set decay with a high value, so the periodical updater stops when the response is the same.

Lukas Renggli wrote

> The problem takes pleace where the text is in bold

Most people use plain text mail clients only.

Didn't noticed that, thanks and apologies

Lukas Renggli wrote

> MyComponent>>renderContentOn:html
>    html div id:'div' with:'some content'.

There seems to be a semicolon missing.

>    (html submitButton)
>         onClick: (html evaluator callback: [:script |
>                 [(Delay forSeconds:10)"Simulate long running process".

At least in Squeak you have to send #wait to the delay to actually start it.

You are right!
I wrote that code in my notepad, didn´t see those errors, the original code doesn´t have them, :s sorry

>                   id: (self attributes at: #id);
<quote author="Lukas Renggli">
You should use #ensureId instead.

>                   decay: 1000;

Lukas Renggli wrote

I dont understand this quite well..

Lukas Renggli wrote

I don't see why you use a decay, because the HTML always changes when
you are rendering a link or form element. A decay of 1000 doesn't make
much sense, that's far too big. Reasonable values are something
between 1 and 2.

I use a decay to stop polling when the server side processing is done: while the process is being executed different hidden inputs are rendered, thus a different response is sent, after the process is done, the hidden inputs are no longer set and the response starts to be the same. With this mechanism and a high decay value the poll is stopped.
This was posted by Ramon Leon here:
http://www.nabble.com/Ajax-live-updates-tf1922480.html#a5263907
http://www.nabble.com/Displaying-progress-on-a-web-page-tf2115321.html#a5853986 

Lukas Renggli wrote

>                   asynchronous: true;

This is not necessary, as it is the default.

>                   evalScripts: true;

You only need this one if you are on an old version of Scriptaculous.

Didn't know that, thanks!!

I still don´t know why when rendering some stuff the poll stops and when rendering other it goes on and on..

Ok, I didn't understand this trick. I would rather stop the polling as
I showed in my previous post, that cleans up all the resources and
will really stop the whole thing.

> I still don´t know why when rendering some stuff the poll stops and when
> rendering other it goes on and on..

Your HTML changes with every request. The names of the form elements
you render change with every render pass.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> Ok, I didn't understand this trick. I would rather stop the
> polling as I showed in my previous post, that cleans up all
> the resources and will really stop the whole thing.

So would I, but at the time, stop wasn't an available method on SUPerodical.
Seems it is now, cool, hack no longer necessary.

Ramon Leon
http://onsmalltalk.com

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > Ok, I didn't understand this trick. I would rather stop the
> > polling as I showed in my previous post, that cleans up all
> > the resources and will really stop the whole thing.
>
> So would I, but at the time, stop wasn't an available method on SUPerodical.
> Seems it is now, cool, hack no longer necessary.

I always thought that there was such a method, but it probably got
lost sometime. I re-added it to the latest version.

It is always possible to call a JavaScript method by sending the
low-level #call:, #call:with: or #call:withArguments: to a JavaScript
object (this can be compared with #perform:, #perform:with:, ...).

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote

Ok, I didn't understand this trick. I would rather stop the polling as
I showed in my previous post, that cleans up all the resources and
will really stop the whole thing.

Great, i'll look into it

Lukas Renggli wrote

> I still don´t know why when rendering some stuff the poll stops and when
> rendering other it goes on and on..

Your HTML changes with every request. The names of the form elements
you render change with every render pass.

Ok I see, but wouldn't it be logical that that situation arises for every kind of form element? I'm almost sure that when rendering a textInput that doesn't happens and the polling stops.

Thanks Lukas

Leandro

> Ok I see, but wouldn't it be logical that that situation arises for every
> kind of form element? I'm almost sure that when rendering a textInput that
> doesn't happens and the polling stops.

Yes, Seaside does not generate a new name for a text-field if there is
no callback defined. It does so for a checkbox, that should be maybe
fixed to be consistent.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote

> Ok I see, but wouldn't it be logical that that situation arises for every
> kind of form element? I'm almost sure that when rendering a textInput that
> doesn't happens and the polling stops.

Yes, Seaside does not generate a new name for a text-field if there is
no callback defined. It does so for a checkbox, that should be maybe
fixed to be consistent.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
Seaside@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Alright, thanks lukas!