Symphony.

Has anyone ever attempted a method of appending dynamic page url params into the page to be rendered before output in order to resolve additional filters that may be used such as parametrizator or url_segments for instance?

Would something like this even be possible with a Delegate?

Maybe a FrontendParamsPreResolve would be useful?

Yep Entirely possible; haven't got the files here but did it a couple of times on parameter. So I could use these values in data-sources or even within Fl-Language. probably it was FrontendParamsPreResolve or something similar.

Im thinking of a method to filter something like nested cats from section entries so would need to append the each level of nested values into param pool somehow.. might make somple site from index page and nested product listings.

For nested categories what I had done, was I chained the data-sources. First one gets all child categories if they exist (output to param pool) then fetch articles by merging both together.

Obviously if you have more then 2/3 level nesting that would be better. I remember I had to use that particular technique once on a project, where I had an unknown number of nesting. So I just created a DS to fill in params with the different levels.

That's exactly what I'm after.. unknown level of nested data from either parent_field or something similar that allows user to chain data from within entry.

And then based on that level structure provide url params to filter the data on the front end.

Is there any pointers or code sample I could scan over for reference at all? Would be greatly appreciated.

Struggling to see how appending params to the param pool can be filtered if the urlparams in the tblpages is static.

Is there a method to override the tblpages urlparam filters to get the page to listen to a dynamic set of inserted url_param filters?

i.e

If I have a Section called Pages, and I use the parent_field to link entries to parents as needed.

Would I then be able to create a custom DataSource that iterates over each level of chained entries to get the hierarchy I'm after.

So far so good. I see the Parent_Field output in my XML has a node tree of child elements from the one section.

NOW THEN

Can anyone think of a way to take that hierarchy of xml and create a group of elements in the param pool that will also be filters for themselves?

This is the XML output I have:

<entry id="136">
  <title handle="home">Home</title>
  <content><![CDATA[Content here...]]></content>
  <children mode="recursive">
    <entry id="137">
      <title handle="second-page">Second page</title>
      <children>
        <entry id="143">
          <title handle="another-page">Another page</title>
          <children>
            <entry id="144">
              <title handle="boom-third-level-down">Boom - third level down</title>
              <children>
                <entry id="145">
                  <title handle="contact">Contact</title>
                </entry>
              </children>
            </entry>
          </children>
        </entry>
      </children>
    </entry>
  </children>
</entry>

So we'd end up with 4 levels deep and 4 URL-Param fiters would need to be created.

<custom-param-level-1>
<custom-param-level-2>
<custom-param-level-3>
<custom-param-level-3>

Could these 4 url_parameters be injected at runtime as page filters so that a url structure like this:

http://rootofsite/(rootpage or index)/custom-param-level-1/custom-param-level-2/custom-param-level-3/custom-param-level-4/

And then if the ParentField hierarchy gets deeper. The Param level will increase and the Page URLParams will be added to the pool of available filters?

Think deep level category filtration from one section here... i.e Website with multi level page structure from one section.

Possible?

@moonoo: definitely possible with a bit of php magic.

If you know how to create the datasource that does pretty much what you want, and you're just concerned with the params I'd advice you to create a small extension that hooks into the FrontendPrePageResolve delegate.

You should be able to explode the request into an array on the forward slash. Then, check to see if you're on the right page, grab the relevant part of the array, and add the resulting array into the param pool (either directly, or by looping over them and giving them a unique name, I can't remember which one works best).

This might seem like a hell of a task, but it really isn't as hard as it sounds :)

Thanks Huib,

The DS Customisation is where I'm going to struggle I think. Trying to get my head around how I can filter urlparams on a single field (ParentFiled) in order to filter each level of child entries the more url sections I add.

Well, it all depends on how your sections are laid out. If every entry is linked to its parent with a selectbox link to the same section, the way to do it is by adding a LEFT JOIN ... to your query for each parameter in the array.

However, the more I think about this, the more I am sure there is a better way than this to handle your situation :)

Think with me for a moment here: the Contact page does not need the categories above it to identify itself, does it? The ID of the page should be enough. So, if you were to build your URL's like I do (145-contact) that's all you need to resolve the page. The rest of the URL is just decoration.

Now you could use the URL Router extension for this, a rule like /\/index\/(.*)\/([0-9]*)-(.*)\/?/ which maps to /children/$2 should do the trick here. Now you can just filter your datasource as you'd always do: by id which is a hell of a lot faster than by a recursive JOIN.

If that's not going to work for you, you can always try the reflection field to build the url using the parent url. This does require you to resave all entries when the parent changes, but there's an extension for that:). To get the string into symphony, you can use the URL Router again, with the following regex: /\/index/(.*)\// to /children?request=$1, and you can access the request by url-request.

Just some food for thought, I am not sure if these suggestions work (at all) but they might get you a working solution ;)

Thanks Huib,

Do you know the internal logic/process of how the url/params are processed before Page Resolve.

Is it a series of SQL queries based on the JOINS specified in the DataSource dsFiILTERS function?