cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2][PATCH] Allow {1} terminology in pipeline parameters
Date Wed, 06 Dec 2000 21:52:57 GMT
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
> 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

- do we need to pass those (list of) Maps/Lists directly to a sitemap
- 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

> 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.


View raw message