cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Burton <ross.bur...@mail.com>
Subject Re: [C2][PATCH] Allow {1} terminology in pipeline parameters
Date Tue, 05 Dec 2000 21:06:13 GMT
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

Mime
View raw message