Stefano Mazzocchi wrote:
>
<snipped-rationale but="read" and="agreed"/>
>
> +---------------------------------------------+
> | I propose the adoption of the Avalon Block |
> | design pattern to modularize Cocoon's user |
> | level and avoid the increase of disorder. |
> +---------------------------------------------+
>
> This, in short means:
>
> 1) Cocoon will be seen as an empty container. Provides basic framework
> functionalities and block containment, but no feature on its own. This
> explicitly resurrect the IoC pattern used in servlet engines, where the
> functionality is packaged in servlets or webapps and the servlet engine
> only provides services around that, with inverted control.
Good. Forgive me, but I think this calls for a little ASCII art :)
+-------------------------+
| Cocoon Core |
+------------------+ | +-----------------+ |
| Client Interface | <-------> | Flow Controller | |
+------------------+ | +-----------------+ |
| | |
+----------------------------+ | +-----------------+ |
| Block Management Interface | <---> | Block Container | |
+----------------------------+ | +-----------------+ |
+-------------------------+
I think this is more or less what we should aim for ('Flow Controller'
here includes all sitemap/flowmap processing). There will probably be
some overlap within the core components, and cocoon.xconf certainly
won't disappear (but will become a lot more compact).
> 2) User functionality will be encapsulated in Cocoon Blocks. Using
> Cocoon will mean to deploy one or more Cocoon Blocks on top of Cocoon.
> These blocks will be *mounted* on a specific URI point and will be
> called by Cocoon when they need to act (follows the IoC pattern).
Yes, but as Michael already pointed out, it's worth noting that not all
blocks are to be mounted on a 'visual' URI, i.e. some might just provide
certain internal functionality.
> 3) These Cocoon Blocks contain file resources (raw or precompiled) and
> compiled bytecode (as individual classes or JAR libraries).
>
> 4) Each block will have a manifest file that describes itself.
>
> 5) Cocoon will implement a mean for users to create their own blocks
> and to deploy them, with great care to allow their hot-deployment (so,
> withou the need to restart the system).
All good. Eventually we'll undoubtedly have tools for managing these
tasks and versioned block libraries.
> Many will find a great parallel between these Cocoon Blocks and WAR
> files: it's right, WARs were a clear step forward and in the
> installation of servlet-based web applications, but I was part of the
> expert group that designed the concept, there are a few things that I
> don't like:
>
> 1) the notion of 'deployment descriptor' breaks clean IoC. The package
> should *NOT* contain any information about the external system, but only
> information about its internals and, eventually, generic requirements on
> services it needs to operate.
>
> 2) WARs are, themselves, monolythic. Instead, the Avalon Blocks exhibit
> a polymorphic nature and can be 'componentized' in order to create a
> higher functional environment.
>
> 3) because WARs are seen as applications and not modules, there is no
> notion of dependencies, nor ability to perform a portable cross-war
> communication, nor the ability to have polymorphic behavior of services
> presented.
I think the rationale behind .WARs was to define 'complete' deployable
web applications, which explains most of the design decisions, but I
agree that this is not what we need for Cocoon (although it must be
possible to prepackage a complete Cocoon installation inside a .war).
> Ok, now I will describe how I see a cocoon block.
>
> a) Cocoon Blocks are Zip files. Even if less efficiently compressed,
> Zip archives have internal random-access features, unlike tar.gz,
> moreover they are easy to read/write within java and are used for both
> .jar and .war
Agreed.
> b) The proposed archive extension is .cb,
Following up the discussion on the file suffix, of the current
suggestions, I'd vote for '.cob'. Other possibilities include '.block',
'.cblock' and '.cocoon'.
> c) The proposed MIME type is application/vnd.cocoon.block (to be
> registered at IANA)
>
> / -> root of the block
> /BLOCK-INF/ -> container for the block manifests (this directory is
> shielded by Cocoon and will not be directly readable from the external,
> just like it happens for /WEB-INF/ for WARs)
> /BLOCK-INF/lib -> contains the libraries (.jar, .dll, .so)
> /BLOCK-INF/classes -> contains the classes (.class, in their right
> package location, as for WARs)
> /BLOCK-INF/block.xinfo -> XML file that contains the block informations
> along with component roles and configurations, sitemap/flowmap mounting,
> and external block dependencies.
> /** -> all of the remaining resources
OK, no reason to break a pattern that works.
> d) a URI-based protocol will allow polymorphic access to cocoon blocks
> and inter-block sharing of resources. The proposed syntax is
>
> block(role):/path/file
>
> and
>
> block(role):component
>
> for example
>
> block(skin):/stylesheet/document2html.xslt
> block(calendar):date-generator
>
> NOTE: the above is compatile with the URI syntax as described in RFC
> http://www.ietf.org/rfc/rfc2396.txt.
OK, but another possibility would be
block:role:/path/file
block:role:component
which might be more consistent with normal 'protocol handler' syntax,
and perhaps the document referenced above (see the quote below).
<rfc-2396>
3. URI Syntactic Components
The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:
<scheme>:<scheme-specific-part>
An absolute URI contains the name of the scheme being used (<scheme>)
followed by a colon (":") and then a string (the <scheme-specific-
part>) whose interpretation depends on the scheme.
</rfc-2396>
> In case the block role is ambiguous, it will be used as a namespace
> prefix, as in
>
> <map:match ...>
> <map:generate src="block(role):/path/file"
> xmlns:role="http://www.role.com"/>
> <map:transform src="block(role):/path/file"
> xmlns:role="http://www.myrole.org"/>
> </map:match>
>
> if the block-based URI is used in non-namespaced syntax (for example, in
> the flowmap), an API-based solution will be provided.
I would require URIs as identifiers and use 'roles' only for mappings
(as already suggested by Michael). The block descriptor could of course
suggest a default role for convenient deployment.
Good work! This is clearly a step forward.
(: A ;)
--
Antti Koivunen (Mr.) <[EMAIL PROTECTED]>
---------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
