Closed Shinmera closed 9 years ago
A possibility might be to simply provide a function to attempt and reverse-route an URL and let the user worry about template integration as we cannot force a specific templating system. r-clip
could handle that automatically by scanning for href
s, action
s, etc.
The reverse-routing possibly requires an additional extension to the route system to be at all possible, but I'll have to think more about that first.
A similar issue is referring to other modules' pages (such as the login and registration pages of an auth implementation). There's currently no way of doing so while preserving the host domain or without explicitly knowing the subdomain ahead of time. We need some kind of mechanism to compute URIs relative to a module.
This might require an additional field specification in the module definition that declare's the module's subdomain. Such an approach might even be beneficial for documentation and automation purposes. Will have to ponder over the details of such a mechanism and the extents of its effects though.
This has been fixed by the pattern, resources, and reverse-routing systems as per Shirakumo/radiance-core@90b78bcc91e95678a6cb757b297f52b9fe2cabcd Shirakumo/radiance-core@56a9b31f2cb823bcf03f595728d6f7148fac2210 Shirakumo/radiance-core@d3dab0c5c33d6477e8bb198e130272cbdc300de1
Routes can modify and change the address of a Request in arbitrary ways, but the template as delivered by the page might not be able to be relative to the original URL, thus directing the user to a bad, if not even inaccessible page.
There needs to be some kind of easy to use mechanism in place in order to transform URLs in the outputted template to what they're supposed to be according to the user-requested URL. Additionally, there should be tools to differentiate by the targeted URL as determined through routing and the original URL in-code, which is currently not possible.