cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [Ann/RFC] "Sitemap Blocks"
Date Mon, 20 Jun 2005 13:42:24 GMT
Stefano Mazzocchi wrote:

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

>See my comments inlined.
>Daniel Fagerstrom wrote:

>>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?
In block.xml you identify the super block with extension. But for the 
wiring.xml you just list the connections (name and block) to the other 
deployed blocks without any indication on what role they have (requires 
or extends). For the required blocks you get a name from block.xml for 
the extended block it doesn't have (or need to have) a name in block.xml 
but it need a name in wiring.xml so I just introduced the special name 

Maybe it is not necessary to have the extended block at all in 
wiring.xml, but I prefer to have all deployment info available in 
wiring.xml. IMO it seem reasonable that if Í have a block that according 
to its block.xml extends it should be possible 
to deploy it so that it extends

>>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.
I'm not certain that I actually supported "relocation" in the current 
implementation, but it shouldn't be that hard to fix.

>>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.
It wasn't designed to be pretty, it was designed to get the job done 
with a minimal amount of work ;)

>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.
AFAIU, the LinkRewritingTransformer doesn't have any internal knowledge 
about anything, all actual link transformation is done in imput modules 
and connected to attributes and scemes in the configuration:

Highly flexible but not that easy to understand, but if we provide good 
default configuration files it shouldn't be a problem for the users.

> so the link transformer must be able to
>access the block manager and obtain the relative URL of the given stuff.
Any component can find the current block and require it to "absolutize" 
a block: URL,

so it wouldn't be a problemt to write a more a specialized block aware 
link transformer.

>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.
I prefer to avoid black magic in this case, link rewriting is hard 
enough to understand without any "helpfull" automagics. I might change 
my mind when we have got more experience about using block link 
rewriting, maybe it is so natural so that we can make it automatic 
without confusing ourselfes, but I'd rather wait and see.

>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.

No ;) I think that the link rewriting that we allready have (although 
somewhat hacky) in the current block implementation, will simplify link 
handling quite a lot compared to th previous situation without blocks. 
But there is definitively more to do. If wou could write a more detailed 
analysis of link rewritiong it would be really helpfull.

                                  --- o0o ---

Now, to continue the work on the sitemap aspect of blocks we really need 
to apply it in a non trivial application. By doing that we will get more 
experience of the involved concepts. It would also make it easier for 
the rest of the community to see what the sitemap aspect of blocks can 
be used for. There seem to be a large community interest in the 
component aspect of blocks, but not yet in the sitemap aspect. Actually 
using it in a real use case would also increase my and others motivation 
to polish the implementation.

I think that the Linotype would make an excelent use case for 
introducing the current block mechanism in. Are you interested?


View raw message