Stefano Mazzocchi wrote:
Yey!!
Daniel,
you rock! Thanks so much for your continuous work on this!
Thanks :)
See my comments inlined.
Daniel Fagerstrom wrote:
<snip/>
The super block of a block is identified by
/wiring/block/connections/connection/@name='super', see
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/wiring.xml?view=markup
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
"super".
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
http://cocoon.apache.org/blocks/another-block/1.0 it should be possible
to deploy it so that it extends
http://cocoon.apache.org/blocks/another-block/1.0.23.
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
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/test/org/apache/cocoon/components/blocks/test1/sub/.
This module can be used together with the LinkRewriterTransformer
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
from Forrest fame to creta the block link rewriting behaviour described
in the end of http://wiki.apache.org/cocoon/BlocksDefinition.
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:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html.
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
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/input/BlockPathModule.java?view=markup,
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.
Agree.
thoughts?
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?
/Daniel
