{% if request.path == "/en/products/marketplace/accounting" %}
{% set queryparam = queryparam ~ "&category=1" %}
{% endif %}
//etc for all categories
However, that 404s. The filtering works with fine using query strings, but I've been told we need to use a URL path instead.
I know I could do the same thing splitting up the DB into one parent referencing category child tables, but the DB has 20 categories and several of the rows have mulitple categories, which would create duplicate pages under different categories. So that's not ideal.
My first thought was to use a parent db that had each category as a row and all had the main DB as a child table. This allowed the path structure I wanted, and I could then filter the main DB depending on the URL. Whatever the URL was, e.g. if it was /accounting at the end, use that by looking up the relevant id and setting that as the query parameter in the table call.
However, a requirement was to have individual integrations from the main DB on their own page, not under a category (as some have multiple categories, meaning they would have duplicates), e.g. products/marketplace/[integration] not products/marketplace/accounting/[integration] and the above idea doesn't allow for that.
The solution was then a little bit hacky, I duplicated the original DB and I added the categories as rows to that, again setting the child DB as the original main DB. This means the URLs for categories and integrations are all at the same level, as it were. Then I used some if logic to determine whether the URL was one of the categories (e.g. a filtered view) or one of the integrations. If it's one of the categories, it gets the relevant rows from the original DB using the method in the first idea and displays those in the listing view. If it's not, it displays the specific integration page.
So, it involves two DBs that have to be updated alongside one another so they match, which is not ideal, but it was that or create a page for each category (still use the one template and DB) which is more work, especially when we come to translate the site.
My first thought was to use a parent db that had each category as a row and all had the main DB as a child table. This allowed the path structure I wanted, and I could then filter the main DB depending on the URL. Whatever the URL was, e.g. if it was /accounting at the end, use that by looking up the relevant id and setting that as the query parameter in the table call.
However, a requirement was to have individual integrations from the main DB on their own page, not under a category (as some have multiple categories, meaning they would have duplicates), e.g. products/marketplace/[integration] not products/marketplace/accounting/[integration] and the above idea doesn't allow for that.
The solution was then a little bit hacky, I duplicated the original DB and I added the categories as rows to that, again setting the child DB as the original main DB. This means the URLs for categories and integrations are all at the same level, as it were. Then I used some if logic to determine whether the URL was one of the categories (e.g. a filtered view) or one of the integrations. If it's one of the categories, it gets the relevant rows from the original DB using the method in the first idea and displays those in the listing view. If it's not, it displays the specific integration page.
So, it involves two DBs that have to be updated alongside one another so they match, which is not ideal, but it was that or create a page for each category (still use the one template and DB) which is more work, especially when we come to translate the site.
On the path /en/products/marketplace?category=1 {{request.path | pprint}} prints String: /en/products/marketplace (of course).
The path /en/products/marketplace/accounting (for example) doesn't exist so I wouldn't be able to print anything. I thought the HubL code example from dynamic team page would essentially create that path/make that path valid and then show the same info as /en/products/marketplace?category=1.
