On 8/19/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 8/18/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > On 8/17/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
>> >> [EMAIL PROTECTED] wrote:
>> >> > We can fix that for 1.3, and pass the improvements to Cocoon. How
>> >> > about changing the wildcard matcher so it can name variables?
>> >> > <!--
>> >> > /lenyabody-{rendertype}/{publication-id}/{area}/{doctype}/{url} -->
>> >> > <map:match
>> pattern="lenyabody-%rendertype%/%pub%/%area%/%doctype%/%%documentpath%%">
>> >>
>> >> Just a random thought - another option might be to use "named
>> matchers",
>> >> maybe with default values for parameters:
>> >>
>> >> <map:match name="content">
>> >> <map:param name="pubId" default="{page-envelope:publication-id}"/>
>> >> <map:param name="uuid" default="{page-envelope:document-uuid}"/>
>> >> <map:generate src="lenyadoc://{$pubId}/{$uuid} ..."
>> >> ...
>> >> </map:match>
>> >>
>> >> <map:generate type="matcher" src="content">
>> >> <map:parameter name="pubId" value="{1}"/>
>> >> <map:parameter name="uuid" value="{2}"/>
>> >> </map:generate>
>> >> <map:transform ...
>> > I do not understand. How does this apply to naming parts of the URL?
>> It doesn't, it is to provide parameterized pipelines - similar to
>> method calls (name + parameters).
>> > The code in your example does not have a pattern.for the matching.
>> No, the parameters are passed explicitely, not encoded as a URL string.
>
> OK. You were not answering Jörn's complaint.
i think he did, and i like andreas' approach.
it combines the clarity of your named matcher with a clean separation
between parameters and URL matching. this has been my greatest grudge
with cocoon and lenya in particular: how the URL matcher is abused to
pass internal variables until it bleeds, with magic tokens like
"lenyabody-" or even worse, "something.xml", that correspond neither to
files or to actual requests, being only internal hacks to allow for
parameterisation, without really saying so.
in my own code, i have tried to make such hacks explicit by using the
"internal-only" attribute of map:pipeline, which in my personal cocoon
dialect translates to "here be dragons: something clever but
syntactically ugly is being done."
iiuc correctly, andreas' approach would separate the URL space from the
internal parameter space, which is very nice imho.
[This discussion probably belongs on the Cocoon Dev ML, rather than
the Lenya User ML. But we could add the features and passs them back.
While it might help to get input from Lenya Users, it definitely
belongs on a Dev list.
To be fair to Cocoon, pipeline matching is designed for matching URLs
from visitors, and it does that pretty well. It was us Lenya users
that bounce the processing through many internal pipelines.]
I like Andreas' approach. It changes map:match so multiple parameters
including more than one slash are possible. The downside is the API
for a pipeline may not be apparent unless the parameters are specified
in the pipeline. We should require that:
<map:generate src="cocoon:/myPipeline">
<map:param name="id" value="someValue"/>
<map:param name="language" default="de"/>
<map:param name="revision" default="edit"/>
</map:generate>
<map:match pattern="myPipeline">
<map:param name="id" default="/index"/>
<map:param name="language" default="{page-envelope:document-language}"/>
<map:param name="revision" default="live"/>
---
Another approach would be local variables in a pipeline. It allows
explicit naming to the pipeline that uses the variable, rather than
the calling pipeline, but it does not change the calling of a pipeline
with all the variables. This could be used as a verbose version of
the % syntax:
<map:match pattern="myPipeline/*/*/**">
<map:param name="id" default="{1}"/>
<map:param name="language" default="{2}"/>
<map:param name="revision" default="{3}"/>
The important part (to me) is for the variable names to survive into
nested pipelines, so the {../#} syntax can be forgotten.
---
We may want a new element so internal pipelines do not overload the
map:generate, which is already overloaded with "type". Calling
internal pipelines is very different than calling serverpages, jx, and
other generators. Using map:generate disables some abilities such as
map:read. map:resource/map:call already uses named parameters. We
should use that as a template, maybe overloading it with
type="resource" and type="pipeline".
> Your suggestion is for internal pipelines to have the same options as
> map:call/map:resource. Combined with map:match, it could have the
> same effect as my suggestion, sometimes at the cost of having an
> additional pipeline just to name the parameters.
that is a question of the syntax, which certainly can be improved (it
should definitely not be split up into two blocks for something that has
a 1:1 relation.
but the grand concept is "separation of URL matching and parameter
passing", and i'll gratefully trade verbosity for clean separation and
clarity.
> I cannot decide
> which is easier for users to understand. We could implement both as
> they are not mutually exclusive. There is the issue if a <map:param>
> and a %param% have the same name, but let one syntax win the conflicts
> (and do not make any effort to choose one.) Any complaints because
> someone insists on using the same variable name in both syntaxes wins
> a free missile on same-day delivery.
woops. i take the blame for introducing the term "shooting offense" into
the lenya discussion, but to give credit it is solprovider who has
brought that concept to perfection. :)
Thanks. Sorry. I'll stop bombing people.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
