Reading parameters from the XSLT developer

Parameters are passed to you through the WriteXml argument "parameters".

void WriteXml(Dictionary<string, string> parameters, XmlWriter xmlTarget)  
{ … }  

The parameters object contains the parameters that have been defined by the XSLT developer when he/she registered it as a Data Query Definition.

The above Data Query parameter definition will pass 3 entries to the providers parameters dictionary:

  parameters["language"];  // Contains [COM]LCID - the current page language code
  parameters["isPreview"]; // Contains bool indicating a page preview
  parameters["constant"];  // Contains a constant string

All values are passed as strings. Use functions like bool.Parse(parameters["isPreview"]) to cast parameter values to other types.

Note that the names of parameters must be exact matches. Typically Data Query parameter names are prefixed with the “at sign” (@) and you should inform the XSLT developer whether or not you are expecting this. In the sample above the at sign has been omitted.

Data Query parameter definitions can be a source for configuration errors - the XSLT developer might misspell or omit or a parameter, might assign it a bad value or might not have access to proper documentation. You should consider spending some time writing input validation with good feedback like this:

  if (parameters.ContainsKey("language") == false)
  {
      throw new ArgumentException("Parameter 'language' was expected. Must be a valid LCID, i.e. [COM]LCID");
  }

Please note that the dynamic values stated in the example above are always available to you through the Composite.Cms.Pub.RequestInfo.PageRequest class. Almost all the dynamic parameters can be accessed through the Composite APIs and the HTTP Context and you should consider reading these kinds of values from these sources since it can ease deployment for the XSLT developer.