Skip to content

Latest commit

 

History

History
67 lines (42 loc) · 4.11 KB

README.markdown

File metadata and controls

67 lines (42 loc) · 4.11 KB

Parametrisator

  • Version: 1.4
  • Author: Marcin Konicki (http://ahwayakchih.neoni.net)
  • Build Date: 26 July 2013
  • Requirements: Symphony version 2.3.3 or later.

Overview

Parametrisator allows you to use XSLT and XPath to select data from XML (generated by any type of data-source), copy it into parameters and add to the parameter pool used by other data-sources. It works with any type of data-source distributed with Symphony, as long as it is editable and returns XML data.

You can select single XSLT utility for any data-source to "parse"/"modify" its XML data output before it will be handled by Parametrisator and copied into parameters. You can specify one or more XPaths for any data-source. Each of those XPaths will generate one additional parameter.

Original XML data from parametrised data-source will stay untouched. It may be used by pages and utilities as usual.

Installation

  1. Upload the parametrisator folder in this archive to your Symphony extensions folder.
  2. Enable it by selecting the "Parametrisator", choose Enable from the with-selected menu, then click Apply.

Changelog

  • 1.4 Update for Symphony 2.3.3.
  • 1.3 Update for Symphony 2.3. This drops compatibility with Symphony 2.2. Parameter names are now dynamically updated on data-source edit pages.
  • 1.2 Bugfix release.
  • 1.1 Official release. Added support custom parameter names and for passing XML data through additional XSLT, just before data is selected into parameters.
  • 1.0 Internal release.

Usage

  1. Create data-source that should output additional parameters with values based on XML data it generates.
  2. If it is a section data-source, make sure to select "Included Elements" that you want to use as parameters.
  3. Scroll down to "Parametrisator" and enter XPath(s) that will select data. You can select optional XSLT utility, that will be used on XML data just before it is passed to XPath(s).
  4. Save changes.

XPath(s) should select data from data-source root element. For example, if data-source is called "Articles", its root element will be "articles". To select title handles of "articles" into parameter, use: /articles/entry/title/@handle (and remember to select "title" field as one of the "Included Elements"). You can use other parameters in XPath, e.g., /articles/entry/title[@id={$url-id:$ds-other-source-id:42}]/@handle.

Known problems

Interface used on data-source edit pages is JavaScript-only.

If you want to use generated parameters to filter other data-sources, you have to make sure that they are generated before those data-sources are called. For example, if "Articles" has field called "bibliography" which is text area with list of names, and there is section "Books" with field "title", and you want to select Books that were listed in Article:

  1. Create data-source "articles", select "bibliography" as one of "Included Elements".
  2. Enter name: "bibliography-handles". Enter XPath like this (it depends on how bibliography text will be formatted, of course): /articles/entry/bibliography//li[class="book"]/@handle in "Output More Parameters" setting.
  3. Create data-source "books".
  4. Filter it by "title" field, using one of following expressions:
    • {$ds-articles:$ds-articles-bibliography-handles} (if "articles" data-source has "none" selected in "Use Field" parameter output setting),
    • {$ds-articles-bibliography-handles} and set "Required URL Parameter" to $ds-articles (if "articles" data-source was set to output at least one standard parameter too).

When Symphony checks for dependencies, only "standard" parameter names are checked. So $ds-articles-bibliography-handles will not be recognized as a dependency and Symphony may execute data-sources in incorrect order. If "standard" parameter is mentioned in at least one of the filters, required parameter or sorting setting, Symphony will recognize it as dependency, even though that parameter may be empty (or never generated by any data-source).

Things to implement in future

  1. It probably would be better to build interface for data-source edit page on server side, so it would not require JavaScript to be enabled on browser side.