Dynamic Paths
Purple Experience
When configuring Purple apps/websites with dynamic resources, dynamic paths allow views in the Purple Experience to not be accessible under static paths, but to have "placeholders" within them that allow for more generic views.
An example would be the path read/:bundleSlug/:postSlug. On the website, a user gets navigated to an URL like news.example.com/read/2023-01/welcome so the bundleSlug would be 2023-01 and the postSlug welcome.
"placeholders" are specified with :<name>, can not contain slashes
Specific names like contentSlug, postSlug etc should be named here
Open presenter/<issueId> or <brand>/presenter/<issueId>
not supported yet
- Find a view in view.json with an object set in the postView-field.
- First we look for such views, which have the postType-field of the postView-object set to the same postType as the post-content has.
- If none is found, we are looking for a view with the postView-field set, but without a postType set in there. We assume this to be the default-view for any post-content without a specific view for it’s post-type.
- Then we look into all data-sources of the view and it’s complete content-tree.
- There we check if and where in the filter-configuration a variable from the path is used as value. The variables are formatted with a colon, followed by the variable-name, e.g. :contentSlug, in both the path and the value-field of the data-source-filter.
- If we find a filter using such a variable, we are interpolating this path-entry with the value within the post, which is stored at the object-path that equals the filter-key-path.
- To support also variables with values from the post's bundle, we fetch the bundle beforehand and add it to the post-object in the field "bundle".
Example:
- We found a view for the post with a path content/:contentSlug
- Within the content we find a data-source with a filter-configuration (example only contains the variable-matching part) like this: {"properties": {"key": "slug", "value": ":contentSlug"}}
- This config is found due to being the value (":contentSlug") being the same as in the path.
- We now use the value of post.properties.slug to interpolate the variable in the path
- If the post has the value „cool-article“ in properties.slug, the resulting path to navigate to is content/cool-article
Pre-defined variables
Besides the filter-driven interpolation, there are 3 pre-defined variables, which can be used without any matching filter
- :postSlug: get value from properties.slug (will not override path from eventually found filter-configuration)
- :contentSlug: get value from properties.slug (will not override path from eventually found filter-configuration)
- :bundleSlug: get value from properties.slug of the bundle of this post (will override path from eventually found filter-configuration).
- Only one path without a prefix is supported! And it must be the last view, the first matching will always be taken!
- no dynamic nested path segments are supported.
Example: We have a nested taxonomy structure: "mobility" <-- "bikes" <-- "electric" available under /category/mobility/bikes/electric if you want to represent this in the URL, all three layers must be hardcoded, e.g. path: /category/:level1Slug/:level2Slug/:level3Slug
If we add a 4th layer to the taxonomy structure, e.g. "city", a new view must be created with a fourth dynamic segment. Also, the Purple Experience currently has no way to navigate to these nested paths when they are not hardcoded.