forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Date Sun, 15 Dec 2002 04:36:58 GMT
On Sun, Dec 15, 2002 at 03:12:27AM +0100, Bernhard Huber wrote:
> hi,
> i was following the discussion about Cocoon CLI, and about links
> now i checked the sources of LinkTranslator and its usage
> inside of Cocoon.
> I was having a problem about serving content as html, and as
> wml.
> Generating wml, or html content from an xml document was
> no real problem thanks to sitemap, xslt.
> But linking of the document was not that obvious.
> Originally i was using inside of the documents
> <link href="index.html">, but as i was implementing the wml
> stuff i releaized that i once should have
> <link href="index.html">, and <link href="index.wml"> for the
> wml stuff, as link/@href was transformed in the xslt stylesheets
> site2html.xsl, or site2wml.xsl.
> Inspired by the schema/protocol discussiion i now
> use <link href="page:index"/>.
> An action named "link-map-translator" sets the Constants.LINK_OBJECT
> table of the objectModel to a table which returns
> for an href "page:index" index.html, or index.wml depending
> on the extension of the Action src extension values.

Nice :)  I wasn't aware of LinkTranslator, and am just getting started on
a LinkRewriterTransformer, so yours is a very timely email.  I'll have a
go at wrapping the XLink machinery in o.a.c.xml.xlink in a Transformer.

Here's a thought..

Christian Haul, Konstantin and others have created a very cool Input
Module system.  The input module API is roughly a Map: give it a key, and
out comes a value.  For example, using the XMLFileModule, one can
retrieve the value of an XML node with:

  <map:parameter name="skin" value="{myxml:/forrestconf/skin}"/>

With link translation, we need exactly the same thing!  Given a semantic
link, we need to look up a 'real' link.  In particular, to implement a
linkmap, we need exactly XMLFileModule's functionality.  A link like
<link href="site:/primer">, the address 'site:/primer' can be resolved by
looking up a 'site' input module (mapped to an XMLFileModule), which
would then use '/primer' as an XPath expression to look up the node.

Because we have JXPath underlying many InputModules, we now have a _very_
powerful link resolution system.  For example, say we want to implement
an 'info:' scheme for accessing Gump-based project data.  In the short
term, we can fish the info out of module.xml directly using
XMLFileModule.  Then one day when Nicola et al finish ViProM [1], we can
switch to that, with almost no code changes.

At this point, I'd expect many Cocooners to be shouting "FS! We don't
need all of InputModule's power in links. It will overheat users' brains!
Think of the children!".  Well, I personally don't think this is FS at
all: we make simple things easy, hard things possible, all by _reusing_
existing code.  But perhaps I don't have the right notion of what FS is.

So anyway, I'm thinking, how about implementing this as a generic
InputModuleTransformer, which is configured with a) an InputModule, b) an
XPath expression of nodes to transform.  So to transform hrefs in links,
we'd have:

  <map:transformer name="inputmodule" src="o.a.c.t.InputModuleTransformer">

Where 'linkmap' is defined in cocoon.xconf as:

<component-instance name="linkmap" class="o.a.c.c.modules.input.XMLFileModule"
    <file src="context://linkmap.xml"/>

Since XMLFileModule can use any Source, so can our linking system.  Want
to link to whatever's the top Slashdot article?  Add a 'slashdot'
InputModule (in the samples sitemap), and add <link
href="slashdot:/*:RDF/item[1]/title}">Slashdot Headline</link> to your

What do people think?  Is this the base for a majorly cool linking
system, or am I missing something?



> bye bernhard

View raw message