Symphony.

I am evaluating whether or not symphony would make a good CMS for a site I plan on building. The site will consist mostly of static content (and lots of it), however there will be a lot of repetition in this content.

Furthermore long-ish articles on the site might require pagination and each page should (must) be accessible under its own URL.

My understanding of sections is that they serve to provide the authors a way to input content, which can then be pulled up by a data source and forwarded to the page XML which is rendered by the templating XSLT.

However for my needs I will need to do a few things such as:

1. Be able to avoid loading all content from a section. Only load “selected” content based on the value of an URL parameter.
2. Display 404's if an URL parameter does not correspond to data from the data source (i.e. section).
3. Display 404's if an URL parameter is missing.

I thought I should tackle case #3 first. I thought that by adding a required URL parameter to a data source, and checking the redirect-to-404-if-no-results option I might achieve this. Unfortunately, that doesn't work as the data source merely returns an empty parameter element in the page XML.

I could of course detect this in XSLT and add a hack to the PHP code to enable access to the PHP functions (call registerPHPFunctions() on XSLT processor object), I would first like to ask the forum where my train of thought went wrong.

It seems to me that I do not understand the purpose of sections or data sources the way Symphony CMS intends for them to be used.

My understanding of sections is that they serve to provide the authors a way to input content, which can then be pulled up by a data source and forwarded to the page XML which is rendered by the templating XSLT.

Yep, correct :-) Filters are the "WHERE" (in SQL parlance) part of the data source, so yes, you should be using a filter to select only the entries you wish to display on the page.

Case #1 should be covered by using a data source filter. Say your article title text sits inside a field named Title, you could pass a URL Parameter to your page named handle and use this in the filter:

{$handle}

If the handle matches a post Title, you'll get that entry back. If it doesn't match one, you won't get any entries. So be sure to check the "Redirect to 404 if no entries found" in the data source editor, so that eventuality #2 is met (go to a 404 if an article isn't found).

The last one, #3, is easily fixed but is not immediately obvious. If a URL Parameter is used in a data source filter (as above) but its value is not set, then the filter is actually ignored, so in this case you would get all entries returned! It does this so you can re-use the same data source for both a master list and child detail view.

To counter this you can modify your filter to something like:

{$handle:0}

The colon syntax means you're specifying a fallback. If the $handle parameter evaluates to nothing (an empty value) then a value of 0 is used instead. Since you're not going to have an entry with a title of "0", no entries will be found, and you will be redirect to the 404 as intended.

You can see the various filter syntaxes on the Data Source Filters concepts page.

Thanks for explaining this to me more fully. Experimenting a bit more with the filter settings solved my initial issues. On to the next batch ... :-)

For the benefit of the future me and others who might find this via Google:

My problem was that I was trying to filter on == {$param} instead of plain {$param}, combined with writing param in the required parameter field (I guess the similarity with the param_1/param_2 syntax of the page editor URL field tripped me up).

I also found that I do not need to use the {$param:default} syntax if I fill in the required URL parameter field in the data source editor (and tick the redirect-on-empty-result checkbox). It seems preferable not to use a default case, because while I might no about the default-that-should-not-be-used, maintainers down the line might not.

I also found that I do not need to use the {$param:default} syntax if I fill in the required URL parameter field in the data source editor (and tick the redirect-on-empty-result checkbox).

Oh yes, good point. Using that checkbox is much neater than the $param:null_value approach... that's what the checkbox is there for!