Hi lukas

in 1.3 we introduced on:fork: to ensure that for example a system announcement 
is processed even if a user announcement would break for the same registry.
The idea is that on Error the stack is copied and forked and the current 
process is resumed. Now with DynamicVariable (and probably Notification) 
the stack is cut and the resume of the notification or dynamic variable gets 
nuts because it does not find the information it needs.
We believe that on: fork: will really improve the stability of the system (ui 
process, announcement). We want to be able to debug UI process without having 
to rinstall the current process
and all the current magic. I do not want to see the new package system on its 
knees just because somebody registered a broken announcement on a systemEvent 
(it already happened before on:fork:).

Now Igor published a new version of on:fork: that only performs the fork and 
cuts the stack on exception that are not always resuming.
To indicate that an exception is alwaysResuming, it is necessary to define 
alwaysResuming ^ true and we are done.

So we did a try on Glamour Seaside by adding 

DynamicVariable>>alwaysResuming 
        ^ true 

and we are open to suggestion because we are thinking about putting 
Notification >>alwaysResuming 
        ^ true 

So for Seaside it would be good that you introduce such method.

Stef


On Jul 17, 2011, at 7:17 PM, Lukas Renggli wrote:

> Not sure why the request context is suddenly gone in your code.
> 
> It could be that this has something to do with the announcements, the
> implementation changed drastically in Pharo 1.3. I had to revert the
> announcements to the original implementation in OB to make them work.
> 
> Do you properly receive the request context before doing the
> announcement, just to rule out any problems in Seaside? Seaside has
> not really been tested on Pharo 1.3 yet, our builds are all based on
> stable Pharo 1.2.1.
> 
> Lukas
> 
> On 17 July 2011 18:53, Andrei Vasile Chis <[email protected]> wrote:
>> Hi all,
>> 
>> In have a simple case: in an ajax callback I trigger an announcement and in
>> the callback associated with the announcement I try to render a Date object.
>> When I do this I get a WARequestContextNotFound exception.
>> To be more exact I have in a component this function to render the callback
>> link:
>> renderAnnouncementUpdate: html
>>   html anchor
>>     onClick: (html jQuery ajax script: [ :s |
>> script := s.
>> model announce: SGLLinkClickedAnnouncement new ]);
>>       with: 'Update Announcements'
>> The model is initialized when I create the component in:
>> initialize
>> super initialize.
>> model := SGLVerySimplePresentation new.
>> model on: SGLLinkClickedAnnouncement do: [:ann|
>> self onClick: ann].
>> When the announcement is called it will trigger the onclick: method which
>> will do the rendering:
>> onClick: ann
>> self addScripts: script
>> addScripts: s
>> s << (s jQuery: #date1)
>>              html: [ :r | r render: Date today ].
>>       s << (s jQuery: #time1)
>>              html: [ :r | r render: Time now ]
>> However the html: method trigers an WARequestContextNotFound exception.
>> I'v tried this on Pharo 1.3 (running on CogVM) with the latest version of
>> Seaside.
>> The application can be found in the Moose Playground project from
>> http://www.squeaksource.com in the package SGL-Seaside-Problem. Atfer you
>> install the package and
>> start a web server you have to execute "SGLTestComponentMin
>> registerAsApplication: 'SGLTestComponentMin'." to register the application.
>> Am I missing something?
>> Cheers,
>> Andrei
>> 
>> _______________________________________________
>> seaside mailing list
>> [email protected]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> 
> 
> 
> 
> -- 
> Lukas Renggli
> www.lukas-renggli.ch
> 


Reply via email to