Repainting during AJAX callbacks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Repainting during AJAX callbacks

cdavidshaffer
 Before I get too far let me say that I don't know, yet, whether this is
an unnecessary hack or a worthwhile framework.  I'm using it now and
like it but I'd be happy to replace it with something better is people
can tell me what that better thing is :-).

Here's the problem: During an AJAX callback (request, update or script)
sometimes a component unrelated to the one making the callback needs to
be repainted.  Normally this happens as the result of an announcement.
While announcements serve to decouple the components they also prevent
the source of the announcement from knowing to cause this other
component to paint.

Basically this motivates using Comet but I don't like Comet and find
that I don't need Comet's level of "server push" for any of my
applications.  What I need is simply the way tack a little extra
javascript on the end of AJAX calls...

My solution: Repaintable in the Cincom Public Store Repository.  (This
package uses JQuery.)  It is a very simple framework so easily abandoned
if it is the wrong thing to do :-)  Here's how it works:  Components
subclass RPRepaintable (or you merge RPRepaintable's methods into your
component hierarchy if that isn't possible).  You must also use
RPSession or a subclass as your session class for your application.
When a component wants to append javascript onto the end of the current
response to an AJAX request it:

    self repaint: 'some-jquery-selector' using: [:h | "h is a canvas"]

The block with be invoked with a canvas.  Paint on it was you normally
would.  Its contents will be loaded by jQuery into the element(s)
indentified by 'some-jquery-selector' (normally an element id).

To simplify things, if the component wants to be able to completely
repaint itself it can implement the following trio of methods:

renderContentOn: html
    html div
        id: self contentId;
        with: [self paintOn: html]

contentId
    ^'some-unique-id'

paintOn: html

    html text: 'Put your normal renderContentOn: stuff here'


Then, such a component just has to send itself #repaint to repaint its
contents.  So, suppose you receive an announcement and you want to
repaint yourself.  Just do "self repaint".  Its that simple.  It works
whether the original AJAX request was "script" or "html" type.  Sending
#repaint (#repaint:using) during a full-page repaint (normal HTTP
request) does nothing...your component will be painted during the render
phase anyway so normally this is not a problem.

An example is provided in the Public Store Repository
(Repaintable-example).  Some notes:

1) All AJAX requests must either be dataType 'script' or 'html'.  This
means that cases when you don't render anything like:

html div
    onClick: ((html jQuery: #foo) ajax callback: [self foo])

will have to modified to

html div
    onClick: ((html jQuery: #foo) ajax dataType: 'script'; callback:
[self foo])

I think that this this is the result of a bug in Repaintable but I can't
tell.  In practice 99% of my AJAX requests are either html: or script:
requests anyway.  In those cases you don't need to send dataType:.

2) If you are using AJAX for purposes other than sending back HTML or
javascript you might end up with cruft being appended to your responses
:-) as components try to repaint themselves.  This isn't a problem for
me but it might be for those of you using JSON to transfer data etc.
This could be fixed if it becomes a problem for anyone.

So, garbage or pure genius (I know the answer already as it took me
three attempts to spell genius)?

David

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

Levente Uzonyi-2
On Fri, 3 Sep 2010, C. David Shaffer wrote:

> Before I get too far let me say that I don't know, yet, whether this is
> an unnecessary hack or a worthwhile framework.  I'm using it now and
> like it but I'd be happy to replace it with something better is people
> can tell me what that better thing is :-).
>
> Here's the problem: During an AJAX callback (request, update or script)
> sometimes a component unrelated to the one making the callback needs to
> be repainted.  Normally this happens as the result of an announcement.
> While announcements serve to decouple the components they also prevent
> the source of the announcement from knowing to cause this other
> component to paint.
>
> Basically this motivates using Comet but I don't like Comet and find
> that I don't need Comet's level of "server push" for any of my
> applications.  What I need is simply the way tack a little extra
> javascript on the end of AJAX calls...
>
> My solution: Repaintable in the Cincom Public Store Repository.  (This
> package uses JQuery.)  It is a very simple framework so easily abandoned
> if it is the wrong thing to do :-)  Here's how it works:  Components
> subclass RPRepaintable (or you merge RPRepaintable's methods into your
> component hierarchy if that isn't possible).  You must also use
> RPSession or a subclass as your session class for your application.
> When a component wants to append javascript onto the end of the current
> response to an AJAX request it:
>
>    self repaint: 'some-jquery-selector' using: [:h | "h is a canvas"]
>
> The block with be invoked with a canvas.  Paint on it was you normally
> would.  Its contents will be loaded by jQuery into the element(s)
> indentified by 'some-jquery-selector' (normally an element id).
>
> To simplify things, if the component wants to be able to completely
> repaint itself it can implement the following trio of methods:
>
> renderContentOn: html
>    html div
>        id: self contentId;
>        with: [self paintOn: html]
>
> contentId
>    ^'some-unique-id'
>
> paintOn: html
>
>    html text: 'Put your normal renderContentOn: stuff here'
>
>
> Then, such a component just has to send itself #repaint to repaint its
> contents.  So, suppose you receive an announcement and you want to
> repaint yourself.  Just do "self repaint".  Its that simple.  It works
> whether the original AJAX request was "script" or "html" type.  Sending
> #repaint (#repaint:using) during a full-page repaint (normal HTTP
> request) does nothing...your component will be painted during the render
> phase anyway so normally this is not a problem.
>
> An example is provided in the Public Store Repository
> (Repaintable-example).  Some notes:
>
> 1) All AJAX requests must either be dataType 'script' or 'html'.  This
> means that cases when you don't render anything like:
>
> html div
>    onClick: ((html jQuery: #foo) ajax callback: [self foo])
>
> will have to modified to
>
> html div
>    onClick: ((html jQuery: #foo) ajax dataType: 'script'; callback:
> [self foo])
>
> I think that this this is the result of a bug in Repaintable but I can't
> tell.  In practice 99% of my AJAX requests are either html: or script:
> requests anyway.  In those cases you don't need to send dataType:.
>
> 2) If you are using AJAX for purposes other than sending back HTML or
> javascript you might end up with cruft being appended to your responses
> :-) as components try to repaint themselves.  This isn't a problem for
> me but it might be for those of you using JSON to transfer data etc.
> This could be fixed if it becomes a problem for anyone.
>
> So, garbage or pure genius (I know the answer already as it took me
> three attempts to spell genius)?

:) This is how our AX framework worked (AXAnnouncements were extracted
from that). The demo is still available here:
http://axdemo.seasidehosting.st/seaside/ax


Levente

>
> David
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

Bart Gauquie
Is the ax framework available? I'm only finding axannouncements on squeaksource?

Regards,

Bart

On Sat, Sep 4, 2010 at 12:23 AM, Levente Uzonyi <[hidden email]> wrote:
On Fri, 3 Sep 2010, C. David Shaffer wrote:

Before I get too far let me say that I don't know, yet, whether this is
an unnecessary hack or a worthwhile framework.  I'm using it now and
like it but I'd be happy to replace it with something better is people
can tell me what that better thing is :-).

Here's the problem: During an AJAX callback (request, update or script)
sometimes a component unrelated to the one making the callback needs to
be repainted.  Normally this happens as the result of an announcement.
While announcements serve to decouple the components they also prevent
the source of the announcement from knowing to cause this other
component to paint.

Basically this motivates using Comet but I don't like Comet and find
that I don't need Comet's level of "server push" for any of my
applications.  What I need is simply the way tack a little extra
javascript on the end of AJAX calls...

My solution: Repaintable in the Cincom Public Store Repository.  (This
package uses JQuery.)  It is a very simple framework so easily abandoned
if it is the wrong thing to do :-)  Here's how it works:  Components
subclass RPRepaintable (or you merge RPRepaintable's methods into your
component hierarchy if that isn't possible).  You must also use
RPSession or a subclass as your session class for your application.
When a component wants to append javascript onto the end of the current
response to an AJAX request it:

  self repaint: 'some-jquery-selector' using: [:h | "h is a canvas"]

The block with be invoked with a canvas.  Paint on it was you normally
would.  Its contents will be loaded by jQuery into the element(s)
indentified by 'some-jquery-selector' (normally an element id).

To simplify things, if the component wants to be able to completely
repaint itself it can implement the following trio of methods:

renderContentOn: html
  html div
      id: self contentId;
      with: [self paintOn: html]

contentId
  ^'some-unique-id'

paintOn: html

  html text: 'Put your normal renderContentOn: stuff here'


Then, such a component just has to send itself #repaint to repaint its
contents.  So, suppose you receive an announcement and you want to
repaint yourself.  Just do "self repaint".  Its that simple.  It works
whether the original AJAX request was "script" or "html" type.  Sending
#repaint (#repaint:using) during a full-page repaint (normal HTTP
request) does nothing...your component will be painted during the render
phase anyway so normally this is not a problem.

An example is provided in the Public Store Repository
(Repaintable-example).  Some notes:

1) All AJAX requests must either be dataType 'script' or 'html'.  This
means that cases when you don't render anything like:

html div
  onClick: ((html jQuery: #foo) ajax callback: [self foo])

will have to modified to

html div
  onClick: ((html jQuery: #foo) ajax dataType: 'script'; callback:
[self foo])

I think that this this is the result of a bug in Repaintable but I can't
tell.  In practice 99% of my AJAX requests are either html: or script:
requests anyway.  In those cases you don't need to send dataType:.

2) If you are using AJAX for purposes other than sending back HTML or
javascript you might end up with cruft being appended to your responses
:-) as components try to repaint themselves.  This isn't a problem for
me but it might be for those of you using JSON to transfer data etc.
This could be fixed if it becomes a problem for anyone.

So, garbage or pure genius (I know the answer already as it took me
three attempts to spell genius)?

:) This is how our AX framework worked (AXAnnouncements were extracted from that). The demo is still available here: http://axdemo.seasidehosting.st/seaside/ax


Levente



David

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

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



--
imagination is more important than knowledge - Albert Einstein
Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein
Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein
The true sign of intelligence is not knowledge but imagination. - Albert Einstein
However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill
It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

Levente Uzonyi-2
On Tue, 7 Sep 2010, Bart Gauquie wrote:

> Is the ax framework available? I'm only finding axannouncements on

No it's not. Maybe we can make it available, but it doesn't have much
value because:
- it was our first Smalltalk framework (we were new to Smalltalk at the
time)
- it uses Prototype + Seaside 2.8
- it's 4 years old
- IIRC it was only tested with Firefox


Levente

> squeaksource?
>
> Regards,
>
> Bart
>
> On Sat, Sep 4, 2010 at 12:23 AM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Fri, 3 Sep 2010, C. David Shaffer wrote:
>>
>>  Before I get too far let me say that I don't know, yet, whether this is
>>> an unnecessary hack or a worthwhile framework.  I'm using it now and
>>> like it but I'd be happy to replace it with something better is people
>>> can tell me what that better thing is :-).
>>>
>>> Here's the problem: During an AJAX callback (request, update or script)
>>> sometimes a component unrelated to the one making the callback needs to
>>> be repainted.  Normally this happens as the result of an announcement.
>>> While announcements serve to decouple the components they also prevent
>>> the source of the announcement from knowing to cause this other
>>> component to paint.
>>>
>>> Basically this motivates using Comet but I don't like Comet and find
>>> that I don't need Comet's level of "server push" for any of my
>>> applications.  What I need is simply the way tack a little extra
>>> javascript on the end of AJAX calls...
>>>
>>> My solution: Repaintable in the Cincom Public Store Repository.  (This
>>> package uses JQuery.)  It is a very simple framework so easily abandoned
>>> if it is the wrong thing to do :-)  Here's how it works:  Components
>>> subclass RPRepaintable (or you merge RPRepaintable's methods into your
>>> component hierarchy if that isn't possible).  You must also use
>>> RPSession or a subclass as your session class for your application.
>>> When a component wants to append javascript onto the end of the current
>>> response to an AJAX request it:
>>>
>>>   self repaint: 'some-jquery-selector' using: [:h | "h is a canvas"]
>>>
>>> The block with be invoked with a canvas.  Paint on it was you normally
>>> would.  Its contents will be loaded by jQuery into the element(s)
>>> indentified by 'some-jquery-selector' (normally an element id).
>>>
>>> To simplify things, if the component wants to be able to completely
>>> repaint itself it can implement the following trio of methods:
>>>
>>> renderContentOn: html
>>>   html div
>>>       id: self contentId;
>>>       with: [self paintOn: html]
>>>
>>> contentId
>>>   ^'some-unique-id'
>>>
>>> paintOn: html
>>>
>>>   html text: 'Put your normal renderContentOn: stuff here'
>>>
>>>
>>> Then, such a component just has to send itself #repaint to repaint its
>>> contents.  So, suppose you receive an announcement and you want to
>>> repaint yourself.  Just do "self repaint".  Its that simple.  It works
>>> whether the original AJAX request was "script" or "html" type.  Sending
>>> #repaint (#repaint:using) during a full-page repaint (normal HTTP
>>> request) does nothing...your component will be painted during the render
>>> phase anyway so normally this is not a problem.
>>>
>>> An example is provided in the Public Store Repository
>>> (Repaintable-example).  Some notes:
>>>
>>> 1) All AJAX requests must either be dataType 'script' or 'html'.  This
>>> means that cases when you don't render anything like:
>>>
>>> html div
>>>   onClick: ((html jQuery: #foo) ajax callback: [self foo])
>>>
>>> will have to modified to
>>>
>>> html div
>>>   onClick: ((html jQuery: #foo) ajax dataType: 'script'; callback:
>>> [self foo])
>>>
>>> I think that this this is the result of a bug in Repaintable but I can't
>>> tell.  In practice 99% of my AJAX requests are either html: or script:
>>> requests anyway.  In those cases you don't need to send dataType:.
>>>
>>> 2) If you are using AJAX for purposes other than sending back HTML or
>>> javascript you might end up with cruft being appended to your responses
>>> :-) as components try to repaint themselves.  This isn't a problem for
>>> me but it might be for those of you using JSON to transfer data etc.
>>> This could be fixed if it becomes a problem for anyone.
>>>
>>> So, garbage or pure genius (I know the answer already as it took me
>>> three attempts to spell genius)?
>>>
>>
>> :) This is how our AX framework worked (AXAnnouncements were extracted from
>> that). The demo is still available here:
>> http://axdemo.seasidehosting.st/seaside/ax
>>
>>
>> Levente
>>
>>
>>
>>> David
>>>
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>>  _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
>
> --
> imagination is more important than knowledge - Albert Einstein
> Logic will get you from A to B. Imagination will take you everywhere -
> Albert Einstein
> Learn from yesterday, live for today, hope for tomorrow. The important thing
> is not to stop questioning. - Albert Einstein
> The true sign of intelligence is not knowledge but imagination. - Albert
> Einstein
> However beautiful the strategy, you should occasionally look at the results.
> - Sir Winston Churchill
> It's not enough that we do our best; sometimes we have to do what's
> required. - Sir Winston Churchill
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

Runar Jordahl
In reply to this post by cdavidshaffer
David explains his framework for repainting Seaside components in an
earlier post:

2010/9/3 C. David Shaffer <[hidden email]>:
(...)

> Here's the problem: During an AJAX callback (request, update or script)
> sometimes a component unrelated to the one making the callback needs to
> be repainted.  Normally this happens as the result of an announcement.
> While announcements serve to decouple the components they also prevent
> the source of the announcement from knowing to cause this other
> component to paint.
>
> Basically this motivates using Comet but I don't like Comet and find
> that I don't need Comet's level of "server push" for any of my
> applications.  What I need is simply the way tack a little extra
> javascript on the end of AJAX calls...
>
> My solution: Repaintable in the Cincom Public Store Repository.  (This
> package uses JQuery.)  It is a very simple framework so easily abandoned
> if it is the wrong thing to do :-)  Here's how it works:  Components
> subclass RPRepaintable (or you merge RPRepaintable's methods into your
> component hierarchy if that isn't possible).  You must also use
> RPSession or a subclass as your session class for your application.
> When a component wants to append javascript onto the end of the current
> response to an AJAX request it:

I am wondering if anyone ported "Repaintable" to Pharo? Or are there
other alternatives that I can use.

Wouldn't it make sense to support this "out-of-the-box" in Seaside?

Kind regards
Runar
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Repainting during AJAX callbacks

Boris Popov, DeepCove Labs (SNN)
Runar,

Here's a slightly more explicit framework-less approach that seemed to work well for us in a proof-of-concept implementation while keeping fine-grained control over the scripts,

SignInForm>>renderContentOn: html
(html anchor)
 onClick: html jQuery ajax serializeForm , (html jQuery ajax script: [:js | self session announce: (SignedIn script: js)]);
 with: #SignIn << #orca >> 'Sign In'.

BalanceDisplay>>initialize
 self session when: SignedIn do: [:ev | ev script << (ev script jQuery id: 'orca-ss-balance') html: [:r | r render: self]].
 
Hope this helps,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl
Sent: 25 May 2011 15:24
To: Seaside - general discussion
Subject: Re: [Seaside] Repainting during AJAX callbacks

David explains his framework for repainting Seaside components in an earlier post:

2010/9/3 C. David Shaffer <[hidden email]>:
(...)

> Here's the problem: During an AJAX callback (request, update or
> script) sometimes a component unrelated to the one making the callback
> needs to be repainted.  Normally this happens as the result of an announcement.
> While announcements serve to decouple the components they also prevent
> the source of the announcement from knowing to cause this other
> component to paint.
>
> Basically this motivates using Comet but I don't like Comet and find
> that I don't need Comet's level of "server push" for any of my
> applications.  What I need is simply the way tack a little extra
> javascript on the end of AJAX calls...
>
> My solution: Repaintable in the Cincom Public Store Repository.  (This
> package uses JQuery.)  It is a very simple framework so easily
> abandoned if it is the wrong thing to do :-)  Here's how it works:  
> Components subclass RPRepaintable (or you merge RPRepaintable's
> methods into your component hierarchy if that isn't possible).  You
> must also use RPSession or a subclass as your session class for your application.
> When a component wants to append javascript onto the end of the
> current response to an AJAX request it:

I am wondering if anyone ported "Repaintable" to Pharo? Or are there other alternatives that I can use.

Wouldn't it make sense to support this "out-of-the-box" in Seaside?

Kind regards
Runar
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

Runar Jordahl
Thanks Boris! This works great. I can see the need for a
mini-framework for this, but that is easy to build once you get your
example to work.

Boris' example assumes you have an element named 'orca-ss-balance' on
the page. So BalanceDisplay would typically render like this:

html div id: 'orca-ss-balance'; with: [ ... ]

One thing to watch out for when using Boris' example, is creation of
two nested elements with the same ID ('orca-ss-balance') after the
first repaint is done: The first rendering should include the element
with the ID, the second rendering (the repaint) should not include it.
"Repaintable" has logic to take care of this.

Runar

2011/5/25 Boris Popov, DeepCove Labs <[hidden email]>:

> Runar,
>
> Here's a slightly more explicit framework-less approach that seemed to work well for us in a proof-of-concept implementation while keeping fine-grained control over the scripts,
>
> SignInForm>>renderContentOn: html
> (html anchor)
>  onClick: html jQuery ajax serializeForm , (html jQuery ajax script: [:js | self session announce: (SignedIn script: js)]);
>  with: #SignIn << #orca >> 'Sign In'.
>
> BalanceDisplay>>initialize
>  self session when: SignedIn do: [:ev | ev script << (ev script jQuery id: 'orca-ss-balance') html: [:r | r render: self]].
>
> Hope this helps,
>
> -Boris
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl
> Sent: 25 May 2011 15:24
> To: Seaside - general discussion
> Subject: Re: [Seaside] Repainting during AJAX callbacks
>
> David explains his framework for repainting Seaside components in an earlier post:
>
> 2010/9/3 C. David Shaffer <[hidden email]>:
> (...)
>> Here's the problem: During an AJAX callback (request, update or
>> script) sometimes a component unrelated to the one making the callback
>> needs to be repainted.  Normally this happens as the result of an announcement.
>> While announcements serve to decouple the components they also prevent
>> the source of the announcement from knowing to cause this other
>> component to paint.
>>
>> Basically this motivates using Comet but I don't like Comet and find
>> that I don't need Comet's level of "server push" for any of my
>> applications.  What I need is simply the way tack a little extra
>> javascript on the end of AJAX calls...
>>
>> My solution: Repaintable in the Cincom Public Store Repository.  (This
>> package uses JQuery.)  It is a very simple framework so easily
>> abandoned if it is the wrong thing to do :-)  Here's how it works:
>> Components subclass RPRepaintable (or you merge RPRepaintable's
>> methods into your component hierarchy if that isn't possible).  You
>> must also use RPSession or a subclass as your session class for your application.
>> When a component wants to append javascript onto the end of the
>> current response to an AJAX request it:
>
> I am wondering if anyone ported "Repaintable" to Pharo? Or are there other alternatives that I can use.
>
> Wouldn't it make sense to support this "out-of-the-box" in Seaside?
>
> Kind regards
> Runar
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Repainting during AJAX callbacks

Boris Popov, DeepCove Labs (SNN)
Runar,

Indeed, so if you wanted to support proper component re-use you could use a simple pattern like,

Parent>>renderContentOn: html
  childA id: html nextId.
  html div id: childA id; with: childA.
  childB id: html nextId.
  html div id: childB id; with: childB.

Child>>initialize
 self session when: ChildPoked do: [:ev | ev child == self ifTrue: [ev script << (ev script jQuery id: id) html: [:r | r render: self]]].

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Runar Jordahl
Sent: 26 May 2011 09:30
To: Seaside - general discussion
Subject: Re: [Seaside] Repainting during AJAX callbacks

Thanks Boris! This works great. I can see the need for a mini-framework for this, but that is easy to build once you get your example to work.

Boris' example assumes you have an element named 'orca-ss-balance' on the page. So BalanceDisplay would typically render like this:

html div id: 'orca-ss-balance'; with: [ ... ]

One thing to watch out for when using Boris' example, is creation of two nested elements with the same ID ('orca-ss-balance') after the first repaint is done: The first rendering should include the element with the ID, the second rendering (the repaint) should not include it.
"Repaintable" has logic to take care of this.

Runar

2011/5/25 Boris Popov, DeepCove Labs <[hidden email]>:

> Runar,
>
> Here's a slightly more explicit framework-less approach that seemed to
> work well for us in a proof-of-concept implementation while keeping
> fine-grained control over the scripts,
>
> SignInForm>>renderContentOn: html
> (html anchor)
>  onClick: html jQuery ajax serializeForm , (html jQuery ajax script:
> [:js | self session announce: (SignedIn script: js)]);
>  with: #SignIn << #orca >> 'Sign In'.
>
> BalanceDisplay>>initialize
>  self session when: SignedIn do: [:ev | ev script << (ev script jQuery id: 'orca-ss-balance') html: [:r | r render: self]].
>
> Hope this helps,
>
> -Boris
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Runar
> Jordahl
> Sent: 25 May 2011 15:24
> To: Seaside - general discussion
> Subject: Re: [Seaside] Repainting during AJAX callbacks
>
> David explains his framework for repainting Seaside components in an earlier post:
>
> 2010/9/3 C. David Shaffer <[hidden email]>:
> (...)
>> Here's the problem: During an AJAX callback (request, update or
>> script) sometimes a component unrelated to the one making the
>> callback needs to be repainted.  Normally this happens as the result of an announcement.
>> While announcements serve to decouple the components they also
>> prevent the source of the announcement from knowing to cause this
>> other component to paint.
>>
>> Basically this motivates using Comet but I don't like Comet and find
>> that I don't need Comet's level of "server push" for any of my
>> applications.  What I need is simply the way tack a little extra
>> javascript on the end of AJAX calls...
>>
>> My solution: Repaintable in the Cincom Public Store Repository.  
>> (This package uses JQuery.)  It is a very simple framework so easily
>> abandoned if it is the wrong thing to do :-)  Here's how it works:
>> Components subclass RPRepaintable (or you merge RPRepaintable's
>> methods into your component hierarchy if that isn't possible).  You
>> must also use RPSession or a subclass as your session class for your application.
>> When a component wants to append javascript onto the end of the
>> current response to an AJAX request it:
>
> I am wondering if anyone ported "Repaintable" to Pharo? Or are there other alternatives that I can use.
>
> Wouldn't it make sense to support this "out-of-the-box" in Seaside?
>
> Kind regards
> Runar
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Repainting during AJAX callbacks

cdavidshaffer
In reply to this post by Runar Jordahl
On 05/26/11 09:30, Runar Jordahl wrote:

> Thanks Boris! This works great. I can see the need for a
> mini-framework for this, but that is easy to build once you get your
> example to work.
>
> Boris' example assumes you have an element named 'orca-ss-balance' on
> the page. So BalanceDisplay would typically render like this:
>
> html div id: 'orca-ss-balance'; with: [ ... ]
>
> One thing to watch out for when using Boris' example, is creation of
> two nested elements with the same ID ('orca-ss-balance') after the
> first repaint is done: The first rendering should include the element
> with the ID, the second rendering (the repaint) should not include it.
> "Repaintable" has logic to take care of this.
>
> Runar
>

While Repaintable is completely flexible in terms of what gets repainted
and how it is nested it does provide the convenience method #repaint to
handle the common "component in a DIV with a fixed id" pattern.  I use
this a lot and find it quite liberating.  Repaintable also handles the
case when a repaint is requested outside of an ajax callback (for
example, during a normal callback) by simply not repainting the
component (since it will be rendered during the render phase).  This
often happens when a non-ajax callback causes an announcement which
triggers a repaint.

On the negative side Repaintable does not use #render: so ignores any
delegation (or decoration) that the component has.  In practice this
works fine since the DIV that contains the component isn't on the page
if the component has delegated (via #call:, for example) to another
component so re-rendering the component has no effect (except possibly
on performance).  This wasn't a design decision, though, just one of
convenience.  I might work towards full rendering later.  I'm using
Repaintable in a second application under development now so I hope some
of the rough edges will disappear as that project progresses.

David

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