cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [blocks] Changing component strategy
Date Thu, 26 Jan 2006 08:47:01 GMT
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
>> Sylvain Wallez skrev:
>>> and several instances of a given block (e.g. CSS-Skin) with 
>>> different configurations can be handled with a flat central registry,
>> Using the servlet pattern described above, i.e. using a wiring file 
>> as we have decided long time ago.
> <shame>I never had an in-depth look at it...</shame>
I meant factory pattern above, wrote a little bit to fast I guess. 
Anyway, it starting to get time to actually take an in-depth look at the 
block architecture, as it soon will be the default way to use Cocoon in 
trunk. After all my refactoring it is hopefully not that hard to follow 
the code.

I'll write a detailed design document later, when the architecture has 
stabilized. I give a short overview now:


The main servlet, sets up a BlocksContext that handle all inter block 
communication, the logger is set up (much more work is needed here), 
based on wiring.xml the classloader is extended with blocks and the 
BlockManagers are setup. The Servlet.service is handled through a 
request dispatcher in the BlocksContext.

As a result of this thread there will be a global ServiceRegistry that 
is setup in the BlocksManger as well.


Implements ServletContext and contains a few extra members for block 
specific things. All inter block communication (except component lookup) 
is done through this class.


Is also a servlet and is initiated with the BlocksContext, it sets up a 
BlockContext, that is the connection point to the servlet that is setup 
within the BlockManager (e.g. a SitemapServlet). The BlockManager also 
setup an InterBlockServiceManager that is parent manager to the blocks 
own component manager (e.g. a ECMBlockServiceManager) (the 
InterBlockServiceManager will disappear and be replaced with a 
connection to the global ServiceRegistry). Servlet.service is delegated 
to a request dispatcher in the BlockContext.


Implements ServletContext (with a few extra methods) and is the block 
internal servlets only contact to the rest of the system. The 
BlockContext use a call stack where it pushes the BlockContext of the 
blocks that are called through the block protocol. The call stack is 
needed for handling polymorphism. The context parameters are used as 
block attributes. Inter block calls are performed through request 
dispatchers of the BlockContext.

                           --- o0o ---

The above classes are the main players in the block architecture. I 
choose to put all the sitemap related parts of the block design in the 
BlockContext. By doing this the block architecture can be used with any 
servlet, there is nothing Cocoon specific in it. When used within OSGi 
and by making the block protocol available though the URL service, even 
block extension and polymorphism will be available in general servlets.

Beside the above classes where is some classes that not are part of the 
framework but will be used from it: A SitemapServlet, that sets up and 
call the TreeProcessor. Now we waiting for someone to write a 
FlowscriptServlet. There is a ECMBlockServiceManager that embeds ECM++, 
a BlockSource for the block protocol, a BlockAttributeModule for block 
attributes and a BlockPathModule that translates block: URIs to absolute 


View raw message