> Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto:
> > * where repository:{1}.x.y.z exists ==> XYZPipeline
> >
> > We get the right pipeline by querying the repository instead of
> > encoding it in the URL. A further advantage is that the
> rule becomes
> > "listable" as the "where" clause in the match expresses
> what are the
> > allowed values for the wildcard.
Ugo Cei wrote:
> Unless I misinterpret what you mean, we already can do this:
>
> <map:match pattern="*">
> <map:call function="fun">
> <map:parameter name="par" value="{1}"/>
> </map:call>
> </map:match>
>
> function fun() {
> var entity = repo.query("select * from entities where id = " +
> cocoon.parameters.par + " and {x, y, z}");
> cocoon.sendPage("views/XYZPipeline", { entity : entity });
> }
>
> <map:match pattern="XYZPipeline">
> <map:generate type="jx" src="xyz.jx.xml"/>
> ...
> </map:match>
>
> Apart from the obviously contrived example, isn't the Flowscript just
> what we need to "get the right pipeline by querying the repository"?
I was struck by your example because right now we are revising our website
using the same technique you describe, with a single external pipeline
calling a flowscript. (BTW the revised website isn't public yet but should
be ready next month.) We're using a topic map as the metadata repository
(with TM4J). As in Daniel's example it completely decouples the external URL
space from the URLs of internal pipelines.
In the "external" sitemap, we just marshall a couple of parameters out of
the URL and request headers, and pass them to a flowscript. This is the
first time I've used flowscript, but it has been fairly easy to write and
it's worked pretty well.
The flowscript queries the topic map to find the topic to display, and the
appropriate internal pipeline to use. It also looks up other "scope" topics
which define different viewpoints of the other topics. They are such things
as different languages, and (since this is a digital library application) we
also have "simplified" and "scholarly" scopes. The flowscript traverses the
class-instance and superclass-subclass hierarchies between the topics
looking for a jxtemplate to use (in the appropriate scope). Finally it
passes the "content" topic and the "scope" topics (and a basic ontology of
other topics) to the specified jxtemplate pipeline.
> In my sitemaps, public pipelines contain almost only <map:call> and
> <map:read> (for static resources) elements. All "classical"
> generator-transformer-serializer pipelines go into an "internal-only"
> pipeline that can be called from flowscripts only.
>
> Admittedly, this is fine for webapps, and maybe not so much for
> publishing-oriented websites.
Yes I think for webapps you could do the mapping just in javascript, but for
publishing I think you really need a metadata repository of some sort. You
could use an xml document linkbase, as Daniel suggests, or a cms, or a topic
map or rdf store, or a sql db or any number of things.
Con
