cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: svn commit: r292158 [4/4] - in /cocoon: blocks/ajax/ blocks/ajax/trunk/ blocks/ajax/trunk/WEB-INF/ blocks/ajax/trunk/WEB-INF/xconf/ blocks/ajax/trunk/java/ blocks/ajax/trunk/java/org/ blocks/ajax/trunk/java/org/apache/ blocks/ajax/trunk/java/org/apache...
Date Wed, 28 Sep 2005 13:15:24 GMT
Torsten Curdt wrote:

>>>     var bookmark = cocoon.createWebContinuation(ttl);
>>> +    +    // Attach the form to the continuation so that we can  
>>> access by just knowing the continuation id
>>> +    bookmark.setAttribute("form", this.form);
> <snip/>
>>> +        +        Form form = (Form)wk.getAttribute("form");
>>> +        if (form == null) {
>>> +            throw new ProcessingException("No form is attached to  
>>> the continuation");
>>> +        }
> Ah ...I missed that
>> The selection list generator, which is called through an Ajax  
>> request, needs to access data in the form that is currently  
>> displayed. And this form is held by the continuation.
>> Since we don't want to _call_ the continuation but just access some  
>> attached data, the quick'n dirty solution was to use the knowledge  
>> that WebContinuation.getUserObject() returns a FOM_WebContinuation  
>> and from there use Rhino methods to access the "form" property.
>> That seemed bad to me, strongly coupling the SelectionListGenerator  
>> to the flow implementation. I guess Mr JavaFlow will agree on this ;-)
> I cannot hide the reason why I've asked ;-)
>> Then I considered that a continuation is actually an application  
>> scope, just as Context, Session and Request are. The lifetime and  
>> visibility of a continuation is in-between Request and Session. And  
>> other scopes do have attributes that we use to pass data around,  
>> whereas a continuation did not. That's why I added attributes to  
>> Continuation.
>> We can then attach some data to a continuation without being tied  to 
>> the actual flow implementation.
> Hm... I see your point and it does make kinda sense. But still it 
> feels a bit ugly.
> I need to think about that.
> And at the moment is also not yet flow implementation agnostic because 
> javaflow does not provide access to the WebContinuation object but 
> only the underlying java continuation. The only connection to the 
> cocoon machinery is through the continuation execution context.

I see.

> Actually I would like to change this flow machinery a bit anyway. Eg. 
> it would be nice if WebContinuation would be an interface an the flow 
> implementation a WebContinuation factory.

+1. This may allow to avoid this wrapping that happens under the hood 
with this userObject property.

> For full flow serialization support it needs some work anyway.



Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message