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. He thinks too much like
I do. I have had several time-consuming errors because I added
map:act around some code and did not change {#} to {../#}. Adding a
level for map:match is mostly obvious, but I do not know why map:act
adds a level to the variables. Naming the variables removes the
possibility of this issue.
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. 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.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
