Felix Röthenbacher wrote:
Andreas Hartmann schrieb:
Hi Lenya devs,
up to now, the migration to Cocoon 2.2 was mainly a matter of
industriously converting Avalon service manager calls to bean wiring.
Now that the main Java services are working, the next step is to get
the web application to run.
In the beginning I thought that modules could be converted to blocks.
But now I noticed that they are conceptually quite different:
Lenya modules
=============
A Lenya module is a white box. Basically, it is a set of resources.
All resources are exposed and can be addressed using the fallback://
protocol. This way, module A can call module B without explicitly
knowing that B exists. A simple example is the usecase module – you
can register a module X with some usecases, and the usecase module can
execute these usecases because it can just access URIs like
fallback://lenya/modules/X/usecases/foo.jx.
The major disadvantage of this approach is obvious – by exposing all
resources, there is no encapsulation, which makes it very hard to hide
implementation details and preserve backwards compatibility.
An advantage from my point of view is that resources can easily be
customized with the fallback:// protocol. But maybe there is a
better way to achieve this (hooks, callbacks, ...)
One way to make clear what is API and what is implementation would
be to name the packages accordingly (o.a.l.module.xxx.api,
o.a.l.module.xxx.impl).
In the distant future Lenya modules/blocks may change into
(OSGi) bundles. In this regard we could adapt OSGi's common practice
to organize all internal classes in packages under
o.a.l.module.xxx.internal. All other packages would be exported
and be visible for a client (visibility will be enforced by
the OSGi container finally). In the meantime anyone who uses
a class from an internal package must be aware that this is on
your own risk.
- Felix
Cocoon blocks
=============
A block in Cocoon is a black box. It exposes its functionality via
servlet services [1], for an example see [2]. This way, the API
(service) is clearly separated from the implementation (internal
pipelines).
There is one major snag to it – if block A wants to make a call to
block B, it has to know that B exists. This connection has to be
hard-coded in the block servlet declaration. Of course we can't
require our users to register their resource types with all generic
blocks that operate on resources. Patching the files would also very
ugly. I sent a mail to d...@cocoon regarding this issue.
IMO the Cocoon block concept is much clearer and allows for a much
better separation of API and implementation (public service pipelines
vs. private resources).
As Lenya is a Cocoon application itself, I'd tend to adapt Cocoon's
block concept.
- Felix
However, your opinions or suggestions on the relation between modules
and blocks are very much appreciated!
[1]
http://cocoon.apache.org/subprojects/servlet-service/1.0/servlet-service-impl/1.0/1412_1_1.html
[2] http://cocoon.apache.org/2.2/1291_1_1.html
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
