When the GenHelm runtime framework processes a folder-based URL there is a series of checks that take place to try to identify the page to be loaded. Consider the URL:
Recall that the frameworks allows pages to be stored in subfolders. Therefore you could use the command "stow a/b/c" to save a page named a/b/c. If such a page exists, the system would load this page. If a page named a/b/c does not exist, the system would look for a page named a/b. If this page exists, it would be loaded and there is a way that the parameter c can be passed to this page.
Let's suppose the page a/b did not exist, then the system would look for a page named a. In this case, if the page is found there is a way that the parameters b and c could be passed to page a.
Let's look at a better example. Suppose a page named car-info is defined and this page needs a make and a model parameter to look up information about a particular car. One option would be to structure your URLs such as:
There is some evidence that folder-based URLs are better for SEO than URLs with parameters in the query string. Therefore, what we would prefer is to load the above pages using these alternative URLs
So how do we do this?
Well, the secret lies in the URL Parameter setting used by the car-info page. Here we see how this could be set to achieve our goal:
Notice that this parameter is not formatted in the usual way you might expect a URL parameter to be structured. That is using name=value&name2=value2...
Instead it is a list of one or more parameter names separated by a slash.
Let's review what happens when the framework resolves a URL such as www.example.com/car-info/ford/mustang.
Using this technique, one page component can serve many different URLs. Normally the car-info page would be written using the custom model and it would read the car details from a database.
The site object supports a get_url_node method that the car-info page can use to obtain the parameters from the URL:
The parameters object could also be used to obtain the parameter values as in: