cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
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:11:13 GMT
>>     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);


>> +        +        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.

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

For full flow serialization support it needs
some work anyway.


View raw message