Long background process UI ideas?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Long background process UI ideas?

Thelliez
Hello,

How could an end user get some feedback about a long background process?

For now this process is started with something like a System
performOnServer: aTopazScript and the control goes back immediately to
the user. The topaz scripts runs in the background.

Could Seaside automatically refresh a status page on a regular basis?

Suggestions?
Thierry
Reply | Threaded
Open this post in threaded view
|

Re: Long background process UI ideas?

Paul DeBruicker
Hi Theirry,

If you can calculate a % complete number for your process you could
use javascript to poll the server at regular intervals and update a
jQuery-UI progress bar. Something to the effect of:

renderProgressBar: html
        | requestDuration  |
        requestDuration := 5 minutes.
"create the initial progress bar"
        (html div)
                id: 'progress-bar';
                script: (html jQuery new progressbar value:
longRunningProcessPerCentComplete).

"a script that replaces the above progress bar with an updated one
every requestDuration (5 minutes)"
        html
                script:
                        ((html jQuery ajax)
                                script: [ :s |
                                                        s << (s jQuery id: 'progress-bar')
                                                                replaceWith: [ :h |
                                                                        (h div)
                                                                                id: 'progress-bar';
                                                                                script: (html jQuery new progressbar value:
longRunningProcessPerCentComplete) ] ];
                                interval: requestDuration)

Using an interval less than the session timeout would keep the session
alive without the user having to do anything.  I haven't tested what I
wrote above







On Sat, Oct 16, 2010 at 5:53 AM, Thierry Thelliez
<[hidden email]> wrote:

> Hello,
>
> How could an end user get some feedback about a long background process?
>
> For now this process is started with something like a System
> performOnServer: aTopazScript and the control goes back immediately to
> the user. The topaz scripts runs in the background.
>
> Could Seaside automatically refresh a status page on a regular basis?
>
> Suggestions?
> Thierry
>
Reply | Threaded
Open this post in threaded view
|

Re: Long background process UI ideas?

Thelliez
Thanks Paul,

This is indeed something like that I was looking for. I guess that I
really have to migrate to Seaside3.0...


Thierry
Reply | Threaded
Open this post in threaded view
|

Re: Long background process UI ideas?

Paul DeBruicker
Hi Theirry,

I bet you can do it with Scriptaculous or Prototype in Seaside 2.8 but
I don't know how.




Paul

On Sat, Oct 16, 2010 at 9:44 PM, Thierry Thelliez
<[hidden email]> wrote:
> Thanks Paul,
>
> This is indeed something like that I was looking for. I guess that I
> really have to migrate to Seaside3.0...
>
>
> Thierry
>
Reply | Threaded
Open this post in threaded view
|

Re: Long background process UI ideas?

Dale Henrichs
In reply to this post by Thelliez
On 10/15/2010 05:23 PM, Thierry Thelliez wrote:

> Hello,
>
> How could an end user get some feedback about a long background process?
>
> For now this process is started with something like a System
> performOnServer: aTopazScript and the control goes back immediately to
> the user. The topaz scripts runs in the background.
>
> Could Seaside automatically refresh a status page on a regular basis?
>
> Suggestions?
> Thierry

Thierry,

For long background process, you should take a look at this discussion:

   http://forum.world.st/threads-within-a-request-td2335295.html

In it there is a discussion about using a service vm for handling long
running tasks.

Nick Ager put together a Futures implementation that schedules tasks to
be performed by a separate vm ... the service vm framework could use
work, but is usable as it stands.

See Seaside-GemStone-ServiceTask-NickAger.16.mcz in
http://seaside.gemstone.com/ss/Seaside30.html,
http://code.google.com/p/glassdb/wiki/ServiceVMExample, and
http://www.squeaksource.com/Futures.html

Dale