You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2009/02/20 17:35:21 UTC
[2.2] Blocks vs. modules
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.
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
dev@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).
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
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.2] Blocks vs. modules
Posted by Felix Roethenbacher <fr...@apache.org>.
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 dev@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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [2.2] Blocks vs. modules
Posted by Felix Röthenbacher <fr...@apache.org>.
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).
>
> 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
> dev@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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org