Search

Hi guys,

i am having trouble wrapping my head around a supposedly fairly simple thing. i have a page that takes three parameters.

page/param1/param2/param3

not every one is given everytime. i would like to have the data-source treat the ones not given as ALL. Naturally if i only give two parameters (say the 1st and 3rd) it seems as i am giving parameters one and two, leaving the third blank. i would have to set the empty parameter with a placeholder value, but then the data source filters for this value and returns nothing whereas i would like it to return all entries in that case.

page/some_filter/NULL/some_other_filter

There are two concepts of parameters at work in Symphony, page parameters (structure, hierarchical) and url parameters ($_GET, non-hierarchical). It seems you should really be using the latter.

URLs and URIs use hierarchy to drill down through a page structure, or command/resource list respectively, so having a segment of that list set as null goes against the hierarchical nature of URLs and URIs, each next level requires the previous, like a filter for what the next level should be. Thats where url parameters come in: arbitrary information that can either be set or not.

I'd advise that you rethink your apps URL/URI structure a little. Datasources are designed to work like they do. What you're after really requires URL params, and fallbacks like {$url-param2:fallback-value}

EDIT: Corrected syntax

I believe you understand the context rather well. Unfortunately, data sources don't allow a null. I believe you have two approaches you can use to solve your dilemma.

  1. Restructure the parameters so that the preceding one is always required. This might involve rethinking the logic or splitting up this single page into more than one.
  2. Utilize the standard ?foo=bar syntax. In this case, a $url-foo parameter will be created in the XML. This approach would allow you to set only those that are required.

Also, take a look at my article about using the Reflection Field - this is probably your best option if you cannot restructure your pages. Towards the end, I specifically talk about how it helped me devise a better URL structure for a project I was working on.

thanks guys for the replies. i did in the meantime switch to url parameters as. i never really use them because of the url cluttering, but i think if you look at it the way you described it john it makes sense to only use page params for structural stuff.

what i am trying to accomplish is a bidirectional multistep filtering. so i have a page with say products i need to filter by different criteria of which some have relations. e.g:

  • Brand
  • Category (e.g. household, beauty)
  • Range (e.g. shavers, shampoo)
  • Country

a brand has certain categories, so if the user selects a category the brand select changes to account for the brands filtered by that category and vice versa. the country filter is not bound to any other and would simply reduce the number of final products in the set.

i am wondering if i am doing it the right way. i have a section for each filter so i can create new brands, categories etc. i created data sources which output all of these filters (e.g. Brands: All) and corresponding filter data sources (e.g. Brand by Brand ID) but to reduce the output of one filter by each other i would have to crearte relationships via select box link or something. and that for every other filter section. am i right?

i currently have relations in one direction. so the brand is on top and has no relation, a category can belong to one or more brands (select box link with multiple), further down a range can belong to a category. but do i really need to link each section to all others. i dread having to choose category and brand when creating a new range-entry. it might not seem much overhead but it gets worse with every new fiterset you implement.

maybe i am complicating things (i tend to do that) and missing the obvious.

any input is greatly appreciated :)

thanks,
daniel

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details