[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.
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. :)
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
