> Is there some reason which forces you not to copy the > parameters wholesale? Otherwise, use use-request-parameters > and simply ignore the parameters you don't want.
Should have made that clear; if I pass all parameters I can clobber parameters where I don't want the values from the form. Also, not being able to filter out some specific parameters could potentially be a bit of a security hole (we are running generic parameter driven templates). I'd definitely require some way of being able to detect that a parameter was passed to me from the form and was also being set specifically by the sitemap... > You can > also try to override the wholesale parameter import by > passing an empty string for the unwanted parameters That would cause problems when the value I really wanted was defaulted to something else in the stylesheet: I'd then get the wrong value... Since the pipeline is generic at this point I'd have to parse the stylesheet to figure out what the proper defaults are. > You can use an internal pipeline with an request-generator > and an XSLT to filter out unwanted parameters, and aggregate > it to you main source: That could work, but the problem is that the parameters names are mapped to various meta-data and I don't know which ones I want and which ones I don't want until I examine the meta-data. Moving the management of the metadata into an XSLT would in effect mean moving converting a chunk of my action handler logic into an XSLT. Now, (as you may know, if you've caught any of my architectural discussions on the list) I am trying to head that direction anyways, so that's a good long term solution. However, short term this is a problem since we have cases where the action handler is already running a XSLT transform under the covers to evaluate rules on which metadata to pick up (evaluation of metadata about metadata): I'd have to generate the XSLT on the fly in order to filter the parameters properly and that doesn't seem like a very efficient way to get parameters into a stylesheet when all I really want to do is ignore some of them... A better possibility would be to create a custom request generator (moving the metadata handling from the action handler to the generator). This complicates the stylesheet somewhat since you going from being able to use global parameters to (at best) having to use XSLT keys to access the equivalent values. This strikes me as a good way to go except that it could also have performance implications? One of my long goals is, essentially, to replace the sitemap with an XML/XSLT combination that implements mapping as a dynamic rules based system. I'd like to hold off on doing that until I see how the 2.1 flowmap stuff shakes out... --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
