RE: Passing unknown parameters through a site-map

[Hunsberger, Peter]

>> 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.
> If your metadata is XML, you can aggregate it with the
> request parameters in order to filter them.

That would be too simple :-)  At this particular point in time the metadata
comes from a relational database, which is why this particular data mapping
problem is resolved using an action handler and not in an XML/XSLT in the
first place...

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Passing unknown parameters through a site-map

[J.Pietschmann]

Hunsberger, Peter wrote:
> 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.
If your metadata is XML, you can aggregate it with the
request parameters in order to filter them.

J.Pietschmann


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: Passing unknown parameters through a site-map

[Hunsberger, Peter]

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

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Passing unknown parameters through a site-map

[J.Pietschmann]

Hunsberger, Peter wrote:
> I've got a situation where I've got to pass a bunch of parameters with
> unknown names from a (Cocoon generated) HTML form through an action to a
> standard Cocoon pipeline.  There are certain parameters I don't want to pass
> on to the stylesheet so I can't use 
> 
>

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. You can
also try to override the wholesale parameter import by
passing an empty string for the unwanted parameters
 

> However, I can, in my action selectively not copy the unwanted parameters
> into the map (since they have well defined names).  The issue is, how do I
> then pass these onto the transform from the from the sitemap? Normally, I'd
> do something like:
> 
>value="{gunk_data_id}"/>
> 
> to pass on individual parameters.  In this case, since I don't know all the
> parameter names I can't do that.  I basically want to say, pass all the
> parameters in the map returned from the action onto the transform (the
> equivalent of use-action-parameters perhaps?)

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:
  



  
  

  


  
  ...
(beware: untested code)

A filter XSLT can be basically the generic copy-through
template and empty templates for the parameters you don't
want:
   
(beware: element and attr names just guessed).

HTH
J.Pietschmann



-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>