Older Web Views Documentation¶
A Webview is a name created to denote a single page application. Trumpet is being geared to become a library to help create websites where most/all pages are apps. I have managed to shrink the html page served by pyramid to a very small head with one script tag loading requirejs and pointing to the loader for the app. I would love to use another name for this, but naming is probably the hardest part of development.
Server vs. Client¶
Mako templates are very powerful, allowing the author to wield the full power of python when rendering the template. In fact, the templates are versatile enough to bypass writing code in the view callable and put all the logic in the template, although this is generally not the wisest thing to do. The largest problem with using the mako templates is that the code is executed server side, preventing me from being able to protect the service from mistakes or malice. I thought about using a more restrictive template system, but soon realized that the inherent problem was the server side rendering, and the server templates would either have to be too limited to be of more than cosmetic use, or flexible enough to bypass the policy of the server.
This is where client side templating comes to the rescue. With client side templates, it is far more difficult to endanger the service that is being provided. I am expecting the worst of the problems to be dysfunctional pages, although the admin pages that edit the templates should always work. I also see a very slim (I hope!) possibility that bad templates could cause a denial of service, but I don’t expect this to be a problem that occurs often.
The general idea behind REST isn’t really hard to understand. It was having to unlearn the way by which much of the web had already been operating for years. I spent many years knowing nothing of PUT and DELETE, but only being familiar with GET and POST, which I naively treated (loosely) as read/write methods. Now that I look back (and not very far either) I was often using GET to perform both deletions of single objects, as well as attaching relations together.
After learning REST, my ability to write arbitrary url’s to perform a function has been severely hampered, and this is a good thing. I now have only four verbs that I am able to use, and I am completely restricted from putting verbs in the url, or even identifying the url as an action. These restrictions help keep the web services well structured and coherent. In fact, a good REST API decouples the server from the browser, allowing a larger variety of clients to have access to the services.
Moreover, and more especially with css, it can become very time consuming to modify two or more upstream css resources to match the general style of your page.