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:
BlocksManager
-------------
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.
BlocksContext
-------------
Implements ServletContext and contains a few extra members for block
specific things. All inter block communication (except component lookup)
is done through this class.
BlockManager
------------
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.
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
paths.
/Daniel
