[C2][PATCH] Allow {1} terminology in pipeline parameters

[Stuart Roebuck <st...@adolos.co.uk>]

I posted this to cocoon users by accident:


Currently you can make use of matches in the request URL in the src parameter of generators and translators, but not in parameters for translators.

Here is a patch to make this work.  I don't know whether this is something that has already been rejected for other reasons - apologies if it has.

At the same time it may be worth removing "map:param" from this sheet as it fails to construct the param variable and results in a compile time error.

Regards,

Stuart.


Index: src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
===================================================================
RCS file: /home/cvspublic/xml-cocoon/src/org/apache/cocoon/components/language/markup/sitemap/java/Attic/sitemap.xsl,v
retrieving revision 1.1.2.64
diff -u -r1.1.2.64 sitemap.xsl
--- src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl	2000/12/02 11:54:17	1.1.2.64
+++ src/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl	2000/12/05 15:05:03
@@ -696,7 +696,7 @@
 
   <!-- collect parameter definitions -->
   <xsl:template match="map:pipeline//parameter">
-    param.setParameter ("<xsl:value-of select="@name"/>", "<xsl:value-of select="@value"/>");
+    param.setParameter ("<xsl:value-of select="@name"/>", substitute(listOfLists, "<xsl:value-of select="@value"/>"));
   </xsl:template>
 
   <!-- FIXME:(GP) is this still valid? -->


** We are currently experiencing prolonged difficulties with our email **
** provider DIGIWEB and INTERLIANT.  To guarantee that your response   **
** is received, please replace "adolos.com" with "adolos.co.uk".       **

-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                                  Mac OS X, Java, XML, etc.
ADOLOS                                             http://www.adolos.com/

Re: [C2][PATCH] Allow {1} terminology in pipeline parameters

[Giacomo Pati <gi...@apache.org>]

Ross Burton wrote:
> 
> Stuart Roebuck wrote:
> 
> > At the same time it may be worth removing "map:param" from this sheet as
> > it fails to construct the param variable and results in a compile time error.
> 
> I'm against removing map:param for two reasons:
> 1) I first proposed it :-)
> 2) It could prove very usefull
> 
> (if anyone doesn't understand what it is for, have a look at the example
> sitemap in the CVS tree)
> 
> I think that using map:param might need some minor changes in the
> architecure of the sitemap however...
> 
> At present this is how I think the sitemap works:
> 
> There is a Map which is the object model of the request, this contains
> items such as the request and response object, and other arbitary
> objects.
> 
> When a matcher is called they return a List which contains matched items
> from the critera, eg "/**/*.jpg" matched on "test/foo.jpg" would return
> a list {"test", "foo"}.  This list is stored and values from it can be
> used in future sitemap components by referencing them with {x}, when x
> is the index of the entry required.
> 
> I see this as a limitation, in my view of this should work I see
> matchers returning a Map which is merged with the object model. 

I don't think this as a good idea. A while ago we discussed getting rid
of the objectModel Map and use the object in it directly to srengthen
the contracts to Request, Response and Context of the Servlet model. So,
putting another objects into the objectModel doesn't make it clearer.
But where do you see a component needs to access that Map directly and
not passed in via references (be it the src attribute or a parameter
element)?
> Most
> matchers will be based upon file paths so the subexpressions have no
> explicit names so numbering them is the easiest solution, but some
> matchers may return values which have definite names, these names cannot
> be expressed in a List but can in a Map.  

This is exactly the point why I've thrown up that discussion about
changing from List to Map as the return type of matchers.

> Using a map the above example
> returns {"1" => "test", "2" => "foo"}.  In a more elaborate matcher, it
> would be feasible to see return maps of {"protocol" => "http 1.1",
> "username" => "rossb", ...}.
> 
> Then the implementation of {x} can be changed so that instead of x being
> an integer offset in a list, it could be a key in the map.  Finally
> map:param can be used to give an existing object in the map a new name,
> i.e. change {"1" => "test"} to {"path" => "test"}.  Maybe map:rename
> might be better...
> 
> This may not appear to be usefull but it helps to manage contracts
> between the URI-space and the logic.  If it was not possible to relabel
> (that's an even better name) the indicies in the list, an XSP page would
> have to request "1" and "2" from the model, when what it really wants is
> "path" and "filename".

Do you all think it is usefull to pass the hole Map (in fact it is a
ListOfMaps because match elements can be nested and such a nesting can
produce name clashes if we only use one Map). Reflecting it a bid ... I
see that a sitemap maintainer might not know what names a matcher
returns (is this important for him?) so he is not able to pass them to a
generator/transformer. Any suggestions on this?

> In a more complex example a query can be embedded in the URI, which can
> be extracted with a matcher (eg /news/2000/12/02).  If code is written
> which is dependant on the ordering of items in the list, this code will
> break if the URIs change (e.g. to /news/02/12/2000).

If your URI changes that way you are asking for trouble breaking all
contract with your users :)

Ok, lets vote on the following:

- should we change the return type of Matcher and Action from List to
Map?

- do we need to pass those (list of) Maps/Lists directly to a sitemap
component 
or
- should a sitemap admin know (most of) the names a matcher/action might
return in its Map/List to be able to pass them to other components which
needs parameters (this he needs to know anyway). This will also
eliminate the binding of components to names other components create
(indirection)

> Finally, I apologise if any/all of what I have just said is irrelevant
> and/or rubbish - I'm tired and don't have much time to keep up with C2
> at the moment...  Sory guys!

No, no. It make absolute sense.

Giacomo

Re: [C2][PATCH] Allow {1} terminology in pipeline parameters

[Ross Burton <ro...@mail.com>]

Stuart Roebuck wrote:

> At the same time it may be worth removing "map:param" from this sheet as
> it fails to construct the param variable and results in a compile time error.

I'm against removing map:param for two reasons:
1) I first proposed it :-)
2) It could prove very usefull

(if anyone doesn't understand what it is for, have a look at the example
sitemap in the CVS tree)

I think that using map:param might need some minor changes in the
architecure of the sitemap however...

At present this is how I think the sitemap works:

There is a Map which is the object model of the request, this contains
items such as the request and response object, and other arbitary
objects.

When a matcher is called they return a List which contains matched items
from the critera, eg "/**/*.jpg" matched on "test/foo.jpg" would return
a list {"test", "foo"}.  This list is stored and values from it can be
used in future sitemap components by referencing them with {x}, when x
is the index of the entry required.

I see this as a limitation, in my view of this should work I see
matchers returning a Map which is merged with the object model. Most
matchers will be based upon file paths so the subexpressions have no
explicit names so numbering them is the easiest solution, but some
matchers may return values which have definite names, these names cannot
be expressed in a List but can in a Map.  Using a map the above example
returns {"1" => "test", "2" => "foo"}.  In a more elaborate matcher, it
would be feasible to see return maps of {"protocol" => "http 1.1",
"username" => "rossb", ...}.

Then the implementation of {x} can be changed so that instead of x being
an integer offset in a list, it could be a key in the map.  Finally
map:param can be used to give an existing object in the map a new name,
i.e. change {"1" => "test"} to {"path" => "test"}.  Maybe map:rename
might be better...

This may not appear to be usefull but it helps to manage contracts
between the URI-space and the logic.  If it was not possible to relabel
(that's an even better name) the indicies in the list, an XSP page would
have to request "1" and "2" from the model, when what it really wants is
"path" and "filename".

In a more complex example a query can be embedded in the URI, which can
be extracted with a matcher (eg /news/2000/12/02).  If code is written
which is dependant on the ordering of items in the list, this code will
break if the URIs change (e.g. to /news/02/12/2000).


Finally, I apologise if any/all of what I have just said is irrelevant
and/or rubbish - I'm tired and don't have much time to keep up with C2
at the moment...  Sory guys!

Regards,
Ross Burton