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
style.
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
container.
* 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.
/Daniel
