Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
The idea for blocks is that blocks that contain public URLs are
mounted at deploy time at a some root URL, then the URL revriting
transformer translates internal use of symbolic block names to the
public exported ones.
Why would anyone internally use any block: URIs? This should be
totally unnecessary: you can either use relative URIs,
You need to use block:foo: URIs to access resources in other blocks,
block: URIs to use URIs that you want polymorphic behaviour on, and
block:super: for geting an URI from the block that you extend. See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2
for more details.
or construct absolute by passing sitemap prefix into the xslt - same
as we do in existing samples.
Using the LinkRewritingTransformer together with the block-path
module will be so much more convenient (see the cited mail above).
Hm, I found no sample where linkrewriter is necessary [1].
LinkRewritingTransformer isn't part of core so I couldn't use it in the
tests for core. Take a look at the examples in src/webapp, start with
src/webapp/wiring.xml. In the block "sample" there is a use of link
rewriting which at least demonstrates the mechanism although it doesn't
motivate its existence. In the simple-samples2html.xsl I use
"block:/styles/main.css" and "block:/images/cocoon.gif" for loading some
resources that are made available through the sitemap of the block. If I
had redefined "/images/cocoon.gif" and "/styles/main.css" in the sitemap
of the block "mysample" that extends "sample" (which I didn't), the
LinkRewritingTransformer together with the block-path module would have
constructed the right absolute path.
You can achive this kind of behaviour without using the
LinkRewritingTransformer. We use some sitemap design patterns for
achieving block like sitemap inhertitance, at the company I work at. But
the XSLT and sitemap prefixed based link construction becomes really
complicated and is one of the main sources of error when we try to
refactor something.
So at least from my experiences the block aware link rewriting is a must
to keep your applications managable. Stefano obviously felt the same as
he made such a thing an integral part of his original design.
All I saw is usage of block: protocol from the sitemap, which I
understand. I just don't see there are many (any?) usecases for the
block: URIs in the pipelines. Either way I'm thinking it will be
relatively obsure usecase anyway.
See the example above. If you create a webapp that is polymorphically
extensible or that use (sitemap) resources from other blocks, the use of
the block: protocol within your xslt, xhtml, jxtg, xml etc files will be
a must to keep the complexity managable.
/Daniel
