cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Ann/RFC] "Sitemap Blocks"
Date Mon, 13 Jun 2005 16:04:18 GMT


you rock! Thanks so much for your continuous work on this!

See my comments inlined.

Daniel Fagerstrom wrote:
> I have added a first, hopefully working, version of the sitemap aspect
> of real blocks to the trunk. No functionality to get components (not
> even VPCs) yet from the blocks.
> Examples can be found in:
> the implementation is supposed to follow
> and the result of various mail list
> discussions (although I can have missed things).
> Use
> ===
> FS layout
> ---------
> A block has the file system layout
> [cocoon block] [DIR]
>  |
>  +-- COB-INF [DIR]
>       +-- block.xml
>       +-- classes [DIR]
>       +-- lib [DIR]
> according to Where
> block.xml is described in
> [cocoon block] is like an ordinary Cocoon top level directory and
> typically contains a main sitemap, files and sub directories.


> Configuration
> -------------
> block.xml describe where the main sitemap is and all component
> configurations are done from the main sitemap. Either directly in
> map:components or indirectly through an include
> The code in COB-INF/[classes|lib] can be found throgh the local
> classloader


> The deployment configuration including URLs to the blocks is done in
> wiring.xml, Schemas for
> wiring.xml and block.xml can be found in
> Currently no
> deployment tool is integrated so one have to write wiring.xml by hand.

that's fine.

> The super block of a block is identified by
> /wiring/block/connections/connection/@name='super', see
> for an example.

hmmm, I don't get this. why do you need to explicitly identify a super
block? don't you get it directly thru extension?

> The wiring file is used by the BlocksManager to set up all the blocks.
> The BlocksManager is configured to point to the wiring.xml:
> <component role="org.apache.cocoon.components.blocks.BlocksManager"
>            class="org.apache.cocoon.components.blocks.BlocksManager"
>            file="wiring.xml"/>
> All access to blocks goes through the BlocksManager.

Works for me.

> blocks: protocol
> ----------------
> The blocks mount paths from deployment should in principle be used
> before the main sitemap in the (main) webapp is called. But at this
> point I didin't want to touch the core classes e.g. o.a.c.Cocoon or let
> any core components depend on the block infrastrucuture. Therefore I
> instead created a blocks: protocol that can be used in the main sitemap
> to connect to the blocks system:
>   <map:match pattern="**">
>     <map:read src="blocks:/{1}"/>
>   </map:match>

Great idea! I'd like to keep going with this, because sometimes, due to
legacy, you might want to keep the need to position the 'block subspace'
as you please.

> block: protocol
> ---------------
> The block: protocol, ( and
> the blocks version of
> the cocoon: protocol,
>   block:/test
> will call the pipeline with URI test in the root sitemap of the current
> block.
>   block:./test
> will call the pipeline with URI test in the current sitemap of the
> current block. In both cases block inheritance and polymorphism are
> respected (take a look at
> for examples). The reason for not using "://" and ":/" for absolute and
> relative addressing as for the cocoon: protocol is that it doesn't
> follow the, see
> for
> Pier's rant about it.
>   block:foo:/test
> will call the pipeline with URI /test in the block. The extended block
> can be explicitly called by,
>   block:super:/test


> block-property: module
> ----------------------
> A block can have a number of properties that can be given default values
> in block.xml and deployment values in wiring.xml (see examples in
> test3/). The value of a property in the current block can be accessed
> with an input-module,
>   {block-property:foo}
> There is no access to properties in other blocks. The blocks properties
> can be used for things like db URLs and should IMO be block private.


> block-path: module
> ------------------
> A block URI block:foo:/bar where the foo block is mounted at /test can
> be "absoultized" to /test/bar by using the block-path input module,
>   {block-path:foo:/bar}
> see example in
> This module can be used together with the LinkRewriterTransformer
> from Forrest fame to creta the block link rewriting behaviour described
> in the end of

this works, but I don't think it's the prettiest thing we could do.

A better way of achiving link translation would be to allow the
LinkRewritingTransformer to be aware of href="" and src="" attributes
(or configurable other attributes) and make them react on the same
block: protocol used above. so the link transformer must be able to
access the block manager and obtain the relative URL of the given stuff.

I would also go a little further and say that this behavior could be
*transparent* and part of the pipeline implementation itself, but I have
no strong opinion about this and I'm generally against behind-your-back
black magic.

Another thing that might be helpful here, is to allow links to be
'absolutized', when, for example, they need to be (say RSS feeds) and
the cocoon webapp is proxied.

Link translation is hacky today and blocks will force us to think about
how to do it in a better way, let's keep also proxying, absolutization
and session IDs in mind as well.



View raw message