cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] FOM
Date Tue, 27 May 2003 21:19:01 GMT
Stefano Mazzocchi wrote:

>on 5/27/03 4:06 AM Sylvain Wallez wrote:
>
>Object getComponent(id) -> obtains the component indicated by the given ID
>  
>
>>Why don't you use the traditional lookup() name ? Also, release() is 
>>missing. So what about lookupComponent(id) and releaseComponent(id)?
>>    
>>
>
>release() is missing on purpose. It follows the same principle of
>"malloc considered harmful" that Java uses for garbage collection. [and
>the principle that Avalon 5 is supposed to use]
>
>as for changing the name from "get" to "lookup" I'm neutral on this.
>
>  
>
>>An important question, also : how does component management fit with 
>>continuations ?     
>>
>
>if you store your component in a variable, that instance is kept into
>the continuation object.
>
>  
>
>>Can a component be frozen by a continuation and unfrozen 
>>in a different environment ?    
>>
>
>it's not the component that is frozen into the continuation, but it's
>instance. a continuation cannot freeze the state of a java component.
>

Ok. By "component", I actually meant "instance" obtained by lookup() or 
getComponent(). Then we have a big problem here : automatic component 
release is very likely to be handled by the container at special times 
such as end of request processing. This means the continuation will use 
released components, thus eventually leading to concurrent access 
problems since the container is likely to have given the instance to 
someone else through another lookup().

On the other hand, explicit release like we have today means that the 
continuation becomes heavyweight since it keeps references to instances 
that may have been taken out of a pool. And even worse, if a 
continuation is abandoned we have some leaks since the instance is never 
released.

Mmmh... A solution may be to use the catch(break)/catch(continue) to 
release components when a continuation is created, and control this at 
creation time, raising an error if there are still some unreleased 
components. This should do the job, at the price of important 
constraints for the flowscript writer.

>>We could have some hooks that automatically relase components when a continuation
is frozen, but then what about stateful components ?
>>    
>>
>
>Ricardo told me that the EJB community has already discussed these issues extensively
(not for continuations, but for stateful components).
>
>Ricardo, anything to add here?
>

Yes, please.

<snip/>

>>>WARNING: removing load() does *NOT* imply that you have to force all
>>>your flow in one big file. The way to fragment your flow into different
>>>files is to use several <map:script> elements in the <map:flow> section
>>>of the sitemap.
>>>
>>>      
>>>
>>Load support is IMO required because JS lacks an import statement. Not 
>>having it means we'll have to write a <map:script> for the script we 
>>want to use, but also for *all the scripts it depends on*, recursively. 
>>This will be very difficult to manage.
>>    
>>
>
>Hmmm, I see your point, but let me point something out. In the future, I
>foresee something like
>
> <map:flow>
>  <map:script src="block:whatever:/flow/flow.js"/>
>  <map:script src="cocoon:/myDynamicFlow.js"/>
>  <map:script src="myStaticFlow.js"/>
> </map:flow>
>
>since we agreed that blocks only expose a URI space controlled by the
>sitemap (they don't expose resources directly!) you can use a reader to
>get the flow to the dependent block, or you can use a pipeline to
>generate your flow (for example, traducing a workflow written using a
>markup language into the equivalent flow instructions).
>
>Here you have all the machinery you need to compose your flows as you
>like. Recursively.
>
>The difference between the above and load() is thin but real: while
>load() has to be executed at runtime, the <map:script> calls can be done
>at sitemap assembly time. It could have a big impact on runtime
>performance of the flowscripts.
>

Mmmh... what you're stating here is that we can have "families" of 
flowscripts (I was about to write "classes") whose contract is defined 
by the toplevel functions (and hence object classes) they provide, and 
that a sitemap will assemble its flow script by loading an "instance" of 
each of the required "families".

So through it's URI contract, a block will provide not only XML 
processing services, but also flow code. That's interesting...

>>>------- properties ---------
>>>
>>>cocoon.request -> the request object
>>>cocoon.response -> the response object
>>>cocoon.log -> the log object
>>>
>>>NOTE: the absence of the context object is intentional! we couldn't come
>>>up with a reasonable need for such an object at the flow level. So, for
>>>the principle of 'less is more', we don't consider it. Be aware that if
>>>you want to propose its addition, you have to come up with a reason for it.
>>>
>>>      
>>>
>>A simple reason : the context object (the environment one) gives access 
>>to context parameters defined in web.xml. In many situations, this is 
>>where parameters depending on the deployment environment are located, as 
>>it allows the sysadmin to use it's favorite app server GUI to set them 
>>and avoids editing cocoon.xconf. (yes, I've seen some installs being 
>>totally screwed up because the sysadmin didn't knew what a well-formed 
>>XML file was).
>>    
>>
>
>Ok, this is exactly the real-life good point I was looking for. +1 for
>adding context.
>
:-)

>Do you need read/write or read-only could be sufficient? (I would go for
>read-only)
>

AFAIK, the only write method is setAttribute(), which can be used to 
define server-wide data. Considering that flow global variables are 
bound to the session, this may be useful.

<snip/>

>>>---------------------------------------------------------------------------
>>>The Log Object
>>>---------------------------------------------------------------------------
>>>
>>>This is a convenience method to access the cocoon logger. It could be
>>>the same of doing
>>>
>>>cocoon.getComponent(...)
>>>      
>>>
>>Huh ? A logger is not a component.
>>
>
>Why not?
>

Huh ? again ;-)

Or is the notion of component in the FOM different that the one in the 
other parts of Cocoon ?

Mmmh... I know you want to avoid abuses, but at the same time, we must 
not make the flow a strange beast compared to other parts of Cocoon. 
This is especially important if we want to allow users to migrate big 
flows to clean Java classes and new components.

What makes Cocoon so nice is that a few concepts are used to define 
everything : the Avalon component architecture, a few interfaces (didn't 
actually count, but I'm sure the main core interfaces are less than 20), 
and this it. Everything else are implementations built on these few 
abstractions. So let's be careful and keep the FOM consistent with Cocoon.

<snip/>

>Yes. But the problem here is that the sitemap will be come super-verbose
>since you'll have to add such a transformer all over the place.
>
>Well, in my post-2.1 RT on sitemap additions, I will outline the concept
>of "macro components", basically allow you to create an 'overloaded
>serializer' which is, in fact, a composition of a transformer and a
>serializer. Something like
>
> <map:serializers>
>  <map:serializer name="xhtml">
>   <map:transformer name="link-translate"/>
>
Is it "type" here instead of "name" ?

>   <map:serializer/> <-- this is the equivalent of super()
>  </map:serializer>
> </map:serializer>
>
>NOTE: the above is meaningful in a subsitemap where "xhtml" was already
>defined, so the above is a "wrapper" around the original component.
>Alternatively you could have something like
>
> <map:serializers>
>  <map:serializer name="xhtml">
>   <map:transformer src="..."/>
>   <map:serializer src="..."/>
>
Again, shouldn't the two "src" above be "type" ?

>  </map:serializer>
> </map:serializer>
>
>where the components that constitute the fragment are not accessible
>independently, but only aggregated in the macro component.
>
>The above removes the magic and increases readability. In fact, it can
>be applied to all pipeline components (generators, transformers and
>serializers).
>

How is this different from a resource ? Resources also allow to define 
overloaded generators and transformers. So do we really need a new concept ?

>>What about the Avalon context ? Is it omitted on purpose ?
>>    
>>
>yes. do you envision a need for it?
>

Don't know... Still my quest for consistency with the other parts of 
Cocoon ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }




Mime
View raw message