Search

I have been thinking about the required URL parameter option in the data source manager for a while now. It's great to have this option but I've run into situations where I needed to specify a condition that a certain URL parameter is not set.

In my opinion this is a general problem: Every time it is possible to set up a positive condition in the interface (if this parameter is set then ...) the contrary negative condition should be available, too (if this parameter is not set then ...). This way, the logic and usability of the system could be improved essentially and the need for custom tailored data sources could be reduced.

This request is not only related to required URL parameters, it also applies to the filter results option of data sources (and all similar situations where positive or negative decisions can be made).

When having the ability to set up positive and negative conditions even the offset problematic could be solved:

  1. Set up a data source (first article) that returns only the newest entry of a section with all related fields.
  2. Let this data source generate a parameter with the current entry id ($ds-first-article).
  3. Set up a second data source (article list) that return the latest 10 entries of the above mentioned section with only the title field.
  4. Set up a filter rule for the entry id: something like not {$ds-first-article} or {not($ds-first-article)}.

The results are two data sources:

  • The first one returns the newest entry.
  • The second one returns the next 10 entries without repeating the newest one.

Maybe the required URL parameter setting could even be integrated in the filter options.

Hey Nils, this inspired some very interesting discussion at Symphony HQ. There are two different points to do with negation here:

  1. General-purpose negation in filter rules
  2. Improving usability and/or efficiency for pages with required params (i.e. deciding what to do when a URL param is/isn't set)

#1 is easiest. We've had lots of requests for negation operators in DS filters (they even partially existed back in v1.5, I believe), we just never came up with a good way to implement them. The screenshot attached demonstrates our solution to negative filter rules for RC1.

Parts of this are still being worked out, but the main points to note are:

  • The "Filter Method" contains a bunch of small, specific syntax parsers that convert the "Value" into SQL. Extensions will be able to add new methods.
  • Multiple filter rules can apply to the same field, so for example, you could use a negation filter in combination with a "Contains one of..." filter.

#2 is a more difficult problem, due to how pages and URL params work in Symphony. I'm gathering you want to be able to have two data sources on a page, but let only one of them execute, depending on whether a URL param is set.

Alistair mentioned some interesting ideas on this to me last week, and it's something we're putting a lot of thought into, but I don't think we have a clear solution just yet.

With regard to offset, I've already added this to the DS editor. I think something so simple shouldn't require a complex workaround using param output, but it's pretty cool to realise that it can be done using negation filters. I definitely like creative solutions.

This looks very useful indeed.

Thanks for the screenshot, Scott.

I think we'll all have to use the new field filter option to see how and if it really works. But I have a follow-up question: What about a tag field I like to filter by and a filter option where I want to pull all entries tagged with cat and animal but not longhair? Is something like this possible?

What about a tag field I like to filter by and a filter option where I want to pull all entries tagged with cat and animal but not longhair? Is something like this possible?

That's what I meant by multiple filters for the same field. Instead of how it works now, where you can only add one filter per field, in RC1 you'll be able to add however many you like. So for your example, you'd be able to one positive filter for cat and|or animal and one negative filter for longhair.

That's what I meant by multiple filters for the same field.

Oh, I'm sorry - sometimes I get lost between the languages. I just misread your sentence :)

Nils wrote:

I have been thinking about the required URL parameter option in the data source manager for a while now. It's great to have this option but I've run into situations where I needed to specify a condition that a certain URL parameter is not set.

I'd say you've inspired a new feature, but honestly this was all your idea. (See screenshot attached - it's a replacement for the "Required Parameter" option in the DS editor. The last select box has two options: "exists" and "is omitted".) It's such a tiny design refinement, but it makes a huge difference to what's possible with the system.

We'd been trying to solve the same problem for a while, but weren't getting anywhere since we'd been approaching it from the page-level instead. Thanks for the fresh perspective, I'm sure many people will appreciate this feature!

Attachments

Yep, I'll appreciate it for sure.

Very cool, Scott. I'm really looking forward to RC 1 :)

Very nice. This has been something I've wanted for a long time. Thanks, Nils for the inspiration and Scott for the implementation!

Sweet

What if you want to include more than one required parameter? I think this idea is great, but could be extended much further.

There could be a Required parameters section much like Filters section, but it allows you to chain together the value of a parameter, followed by an or or and. Either that or turn the parameter select box into an input field where you can use the {$a:$b} format to chain things together.

Hope to see some awesomeness soon :)

URL Parameters are sequential. For example, http://site.com/page/a/b/c/ - parameters being $a, $b and $c. If $b is required, $a is also required.

@Rowan:

What if you want to include more than one required parameter?

We did consider this. The alternative is to have two multi-select boxes - one for required params and the other for params that prevent execution. There are 3 circumstances that would make this implementation useful over the screenshot example:

  1. A DS is used on two pages, each with differently named params that must prevent execution.
  2. A DS requires multiple params and is used on two pages where these params are in a different order.
  3. A DS is used on a single page with the URL schema "$a/$b/$c" and requires $c but must not execute when $a exists. (Note that this doesn't require multi-selection, just the ability to independently set required and preventing params.)

Both #1 and #2 can be worked around by using two different data sources, leaving #3 as the only real limitation of the screenshot example. Each of these seem to be fairly rare use cases anyway, but the reason we decided not to support #3 comes down to philosophy.

By disallowing #3, a page can have at most 2 mutually exclusive data sets. By allowing #3, a page with n parameters can have up to (n + 1) mutually exclusive data sets. This would blur the distinction between page and URL param, making it possible to effectively create whole websites using only 1 page. It also requires the developer to have greater knowledge of how other DSs and the XSLT respond to missing params/data, which is especially problematic for debugging a site that someone else developed.

Disambiguating has been our main goal with recent changes to Symphony's core field types - we want it to be absolutely clear to a developer what field type should be used for a particular situation, so there shouldn't be any overlap in how two different field types operate. We applied the same reasoning to pages/params.

There could be a 4th use case that I haven't thought of. Can you give me a specific example where the screenshot implementation wouldn't meet your needs?

Bump bump bump…

Would this apply to 2.0.8RC3 also? I need to set a ‘list’ datasource to only display results when a ‘single entry’ datasource has no results so that when the url parameter is set to pull a ‘single entry’, it nullifies the ‘list’.

Is this possible?

This might be what you’re after: Tip: Don’t execute Data Source if a URL parameter is set.

I stumbled across another solution, although it’s a bit of a hack, but it seems to work. Configure the data source to use your entry parameter to define the number of the results page to return.

 Show page {$entry} of results

This has the effect of returning no results if the $entry parameter has a string value. This won’t work if the $entry paramenter returns a number, however (unless the number is high enough that there won’t be that many results, but the query will still run to try to figure out whether there are enough results).

Thanks Stephen!

@designermonkey - you might find the Filter Field extension by ahwayakchih to be helpful. Marcin gives a few helpful examples in this thread. I ran into one problem using the extension, but it was because I was using it incorrectly. Here’s my experience with that problem.

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