- Thomas' Webjar full of joy -
| Author: | Thomas Langewouters |
|---|---|
| description: | Philosophy of the technology behind my ideal website |
| Date: | sept 17 2006 |
One of my programming projects that keeps on going is my personal website. I'm always exploring new technologies and design strategies.
This text currently describes one of my ideas, building onto the idea that having a custom wiki website would be cool. Of course this would be constructed using cool technologies like python and XML templates, backed by a database system.
The truth however is, I am very wary about trusting my work with it. In an ideal situation I would have a strategy at hand to generate static html pages, in case I am forced to switch to a web host that doesn't provide python and the necessary bindings.
As long as I don't have a solid solution, this website will remain to be served as a mixture of static content and small dynamic parts.
A fat wiki would have nice features, like guest comments, dynamic photo albums, stats and more. The project will be implemented in python, with the CGI (common gateway interface). Third party packages will be used to avoid reinventing the wheel.
The underlying framework is based on the model/view/controller paradigm. The presentation layer is powered by kid, a powerful XML based templating system. The data model is powered by SQLObject, python MySQLdb bindings and a MySQL database. SQLObject provides object-oriented access to tables and rows.
Apache's mod_rewrite will rewrite all requests (except those to a static directory) to the gate.py script. This script is quite small, all it does is create an instance of the Dispatcher class and call its .dispatch() method.
Upon dispatcher initialisation, the object initializes a requestfolder whose function is to provide abstracted access to respectively the request's GET, POST and URI variables. A sessionfolder object instance is also created to provide persistent variables to the framework.
The dispatcher solves the request by creating 'solution provider' instances of each 'solution provider' in a list.
The 'solution provider' instance looks at the request URL, and if it is able to provide a solution, it sets it .valid attribute, processes the request and provides a populated template via its attribute .template.
When a solutionprovider's .valid attribute is set after initializing it, the dispatcher breaks out of the loop and loads the page template. This template is the wrapper html skeleton and can read additional information of the solution provider if necessary, since the provider is passed to this template.
As you would expect, the page template shows the provider's .template by including it in its XML stream.
All the solution providers inherit from this class, it provides an __init__ method that should be called from the actual provider class, this __init__ method does some preprocessing of the request argument and calls exposed methods if requested. It also provides default values for attributes like the title ("No Title!"), headers ([]) and exposed methods ([])
Provides listings of all objects of a certain type, and handles requests of webobjects. For handling webobject requests, a group of classes that inherit from webobjectProvider is used. The model's webobject.byfilename() call will return an instance of a SQLObject, eg; article, picture. webobjectProvider will overload itself to eg; articleProvider.
This provider will always return a 404 page, if no other provider will answer the request.
Articles are composed as restructured text, docutils directives are loaded to create the functionality of including other webobjects inline (picture objects or thumbnail galleries of photoalbums).