Webapp Redesign
The Ringo webapp framework is currently (0.6) underspecified and underdocumented piece of code. URL routing is quite complex, yet it misses features such as simple placeholders. On the templating side we only support Ringo skins, with other templating libraries having to invent their own way of hooking into the framework.
This is an attempt to come up with a cleaner and more flexible specificaton of the webapp framework for the 0.7 release.
Problems with the current implementation
There is no way to determine the URL path of an action module. This is important for reverse routing (finding the URL of a given action).
Regular expressions are a very low level way of specifying URL mappings. There should be a higher level patterns such as placeholders and wildcards.
There is no easy way to get at the current request.
ringo/webapp/envprovides this functionality, but maybe there's a better way to do this.The Response object has a
skin()method, but what are other templating libraries supposed to do?There are currently at least 3 ways of serving static resources, and the same is true for many other areas. Reduce options or make it clear why they exist.
The convention that an action function is only invoked if its declared arguments match the remaining path elements breaks delegation.
Goals
Things the Ringo webapp framework should be:
Minimal but extensible: We should not aim to provide every last feature people may expect, but it should be possible to implement these on top of Ringo webapp.
Mountable/Stackable: It should be possible to combine several apps into one. Webapps should be agnostic regarding their base URL path and should be able to share a common base layout.
JSGI compliant: Ringo webapps should adhere to the JSGI spec and extend it sensibly.
Agnostic: the webapp framework should not make any assumptions about rendering or database frameworks being used.
Routing
The current problems with URL routing (see section above) are that reverse routing (finding the URL for this or a related action) does not work reliably, and regular expression based mapping is too low level for many uses.
Reverse routing is important for mountable/stackable apps. An app should be able to generate URLs easily regardless of where it lives in the server's URL space.
To implement reverse routing, there must be a way to map action and application modules back to URLs. The reasons this currently is hard or impossible are:
- URLs may be mapped to a module/action tuple, and the mapping may include parameter groups
- URLs may be mapped to modules using RegExps instead of literal paths
It seems to make URL mapping work both ways we need to prevent the above things from happening. Thus, 1. a URL can either be mapped to a module or a function, but not both, and 2. a mapping to a module must use a literal path string as key.
This would imply that config.js files would only define mappings to the app's action modules or embedded app's config modules, but the intra-module dispatching would be left to the action modules themselves, which would either use "natural" URL mapping (mapping path elements to names of exported functions and their parameters), or exporting their own urls definition mapping requests to internal functions. Mapping a request to a function would require the actual function object to be used, not a module/function name tuple.
The result would be that the same basic URL mapping mechanism would be used on all all levels, be it embedding one app into another, mapping a URL prefix to an action module, or dispatching a request within an action module.
Templating
To support pluggable templating engines, the Response.skin() method should be replaced with a generic Response.render(). We need a way to register templating engines with the Response object by extension or as default engines.
Another area where we should help app writers is locating and reading template files. Currently, resolving and reading resources is left to the app developer. A simple way to fix this would be to register locations for template resources once to be able to refer to templates using just the resource name, e.g. index.tmpl.
