cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Futher block-fw development
Date Thu, 02 Feb 2006 15:37:41 GMT
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>> I have not that much problem with the sitemap stuff, it shouldn't be 
>> that hard to migrate them. I'm more concerned about the Core and 
>> Settings objects, that is part of the trunk contract and that doesn't 
>> fit well into a splited up non-monolithic architecture.
> Hmm, which external contracts are affected by how the "framework" works? 
> The only contract I see is where block.xml is located 
> (/META-INF/block.xml) and which XML (defined by the namespace). This way 
> the framework (and the deployer) find out whether they can work with a 
> given block or not. Do you see any other dependencies?

Ok, I talked about a 2.2 release in general, the block fw is a separate 
concern and shouldn't be affected by the mentioned objects (except that 
it has been a real pain to refactor away the dependence on them and that 
there still is some work to be done).

> Currently you can configure the deployer which blocks-fw you want to use 
> (which is the actual core IMHO) and blocks-fw depends on the legacy 
> core. As said, this is completly unrelated to the blocks.

My intension is to remove the block fw dependencies on cocoon-core, 
still some work left.

>>> Do you have a roadmap on what's open?
>> * Component handling - design issues
> ok, that's the main question that needs to be answered
>> * Logging - I put it in the BlocksManager but didn't give it much 
>> thought, here is a new chance for all logging enthusiasts to discuss ;)
> hehe

I don't know that much about logging. But my main thoughts is that 
logging need to be a centralized service, common for all blocks 
(separate logging solutions for each block would be a pain).

The logging implementation is contained in a block (that is installed 
early) and makes the logger available as a service that other block can 
get through the service manager. This way the logging implementation is 
chosen by the choice of logging block. Observe that I only is talking 
about the blocks fw, within a block an ordinary ECM can be set up and it 
will inject the logger in its managed objects through the usual Avalon 

Using the same logger interface everywhere is also practical I guess we 
continue to use the o.a.avalon.framework.logger.Logger one.

>> * Multi part MIME handling - not part of the blocks architecture to 
>> simplify things, would make most sense to put in a ServletFilter IMO
> ok (haven't thought about this yet)

I think it makes most sense to let multi part MIME be centralized and at 
the start of the call chain, it doesn't make sense to have it at the 
block level AFAICS. So we could make it part of the BlocksManager, but I 
prefer to keep the BlocksManager focused, so a filter before the 
BlocksManager seem to be a good alternative.

That also means that the multi part MIME handler is reusable for others 
(or that we can use another implementation if we want). Setting up a 
filter isn't such a big deal, so it is easy to do even outside a servlet 

>> * Error handling - there is sophisticated creation of error messages 
>> in the CocoonServlet, where is the right place for it in the blocks 
>> architecture?
> ok (haven't thought about this yet either)

Neither have I.

>> * JARed blocks - the BlocksManager assumes that the wiring location 
>> points to unpacked blocks, implement support for packed blocks.
> ok, IMHO a nice to have for me and transparent for the user.
> Do you mind if I create JIRA tasks for them? I would like to use the 
> roadmap feature of JIRA to make it visible for lurkes on what we are doing.

Quite the opposite, JIRA issues would be good.


View raw message