[Seaside] 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 <boris at deepcovelabs.com>:
> 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: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-bounces at lists.squeakfoundation.org] 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 <cdshaffer at acm.org>:
> (...)
>> 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
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>