Ugo Cei wrote:
Il giorno 06/gen/05, alle 01:54, Daniel Fagerstrom ha scritto:
The requested resource will often be based on some content or
combination of content that we can access from Cocoon. The content can
be a file, data in a db, result from a business object etc. Let us
assume that it resides in some kind of content repository. Now if we
think about it, isn't it more natural to ask the content, that we are
going to use, about its propertiies like type, format, status, access
rights, etc, than to encode it in the URL? This properties can be
encoded in the file name, in metadata in some property file, within
the file, in a DB etc. Now instead of having the rule:
*.x.y.z ==> XYZPipeline
we have
* where repository:{1} have properites {x, y, z} ==> XYZPipeline
or
* 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.
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 would propose to go even further, in the "real" site map it should
only be allowed to call VPC pipelines, no pipeline construction is
allowed, that should be done in the component area.
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. But what I want to point out is that your
otherwise very well thought-out RT is incomplete if it doesn't take
Flowscript in consideration, IMHO.
I started to write a very similar answer (example + considering flowscript)
Thanks Ugo ;-)
--
Reinhard
