Andreas Hartmann wrote:
Jörn Nettingsmeier schrieb:
looking at the new {link:} input module, i wonder why we really need it.
iiuc, all it does is provide a means to access a request parameter. it
does not possess any specific knowledge about link semantics.
why not just use the generic {request-param} module? or do you have
plans for the future where this abstraction might become useful?
I totally share your concerns. I hesitated quite long before I
committed this, but I didn't find a better solution.
so let me try to convince you to get rid of it...
moreover, i don't like the fact that the module returns a complete
expression "rev=<xxxx>". that way, invocations look ugly:
<map:generate
src="lenya-document:{page-envelope:document-uuid},lang={page-envelope:document-language}{link:rev}"/>
i would prefer if it read "link={link:rev}",
Hmm, what would link=... mean?
stupid typo on my part. that should of course read "rev={link:rev}"....
since the lenya-document
invocation must know about the "link=" semantics anyway - we don't win
anything if the input module hides it, it becomes harder to re-use in
different contexts, and the invocation is harder to read.
The problem is that the revision parameter is optional. Therefore I
didn't use
,rev={request-param:lenya.revision}
This could result in an empty rev parameter value, which should IMO
cause an exception.
why?
it would only be an issue if we needed to differentiate between "empty
value" (i.e. "rev=") and "unspecified value" (i.e. rev does not occur).
but i cannot see why we would want to.
so my suggestion is to treat the unspecified value just like the empty
value and get rid of the input module.
<map:generate
src="lenya-document:{page-envelope:document-uuid},lang={page-envelope:document-language},rev={request-param:lenya.revision}"/>
(although i'd have to check what the request-param input module does if
the parameter does not exist - i'm assuming it will yield an empty
string. if it doesn't, one more reason for a lenya-request-param module.)
on second thought, rather than accessing lenya-internal request
parameters directly via the generic cocoon {request-param} module, maybe
we should provide a {lenya-request-param:} module that will yield values
of parameters in the "lenya.*" parameter namespace.
That would be {request-param:lenya.foo} vs. {lenya-request-param:foo}.
IMO we don't need this abstraction here, but it's OK with me to
introduce it.
it does not have any advantages in itself, but if we use it throughout
our code, a simple grep for "{request-param" would show all places where
we pollute the global namespaces.
Well, maybe this could be approximately done with
\{request\-param\:.{5}[^\.]
if the probability that the dot occurs at the 6th position is
small enough.
that's certainly true, but having a lenya-request-param module will make
new contributors do the Right Thing when they learn by example - coding
best practises are made obvious in the code (which is even better than
documenting them).
test-grepping with a complex regex does not have this educational value ;)
regards,
jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
