forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: [RT] InputModuleTransformer for linking (Re: [RT] LinkTranslator Usage)
Date Mon, 16 Dec 2002 08:51:55 GMT
On 15.Dec.2002 -- 03:36 PM, Jeff Turner wrote:
> 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:transformers>
>   <map:transformer name="inputmodule" src="o.a.c.t.InputModuleTransformer">
>     <input-module>linkmap</input-module>
>     ...
>     <transformed-nodes>//link/@href</transformed-nodes>
>   </map:transformer>
> </map:transformers>
> 
> 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"/>
> </component-instance>
> 
> 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
> XML.
> 
> What do people think?  Is this the base for a majorly cool linking
> system, or am I missing something?

Jeff,
I think this is a great idea! Some ideas:

*) It might be nice to use the syntax from sitemap, i.e. the
   transformer would not be bound to a single module but dynamically
   look them up "{linkmap:something}" 
   I guess the "..." above indicate that more than one module may be
   used but I wonder what it buys to have their declaration locally to
   the transformer. Granted, this way you can deviate from the global
   configuration of a module.
   Maybe the transformer could use all modules and use a special
   configuration for those listed in the configuration section?

   For the input.xsl logicsheet I have created a simple helper class
   that handles a list of modules during execution. Perhaps this class
   could be used by the transformer (would need some additions for the
   configurations):
   o.a.c.components.language.markup.xsp.XSPModuleHelper.java

*) limiting the transformer to nodes matching an XPath expression is
   cool. But it might be expensive: It might require the transformer
   to keep / build a DOM representation of the document so that the
   XPathProcessor can be used.
   
   Alternatives could be to act on every attribute (expensive), act on
   every attribute of elements belonging to the target namespace, dito
   but only certain attributes or specific elements. Those could be
   decided without knowledge of the rest of the document but appear
   not to restrict the application too much.

Cheers,

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Mime
View raw message