So, I signed my first client.

Part of job is to add dynamic content to portions of a large commercial (mostly static) site. After a closer look, I realized the base content can be templated with Django's template system. Then I wrote a catch-all view and locate the page's old url from the model. So besides the headers and footers, the old content is now pulled in from the database itself. This was preferable because I was able to also give some versioning tools to the content itself (although static blocks).

So my setup looks something like this:

  Framework    Configure        Render
+------------+-----------+---------------------+  
|    v       | v         |                     |
|Apache2     |httpd.conf | Branding Logo       |
|mod_python  | v         |                     |
|    v       |settings.py| Navigation / Search |
|Python2.4   | v         |                     |
|    v       |url.py     | Navigation Crumbs   |
|Django      | v         |                  <------ (later: Login bar here)
|SQLObject   |view.py    | Content (cached)    |
|psycopg     | v         |                     |
|PostgreSQL  |model.py   | Footer              |
+------------+-----------+---------------------+  

This is the view:

def base(request,template="sample/base"):
   if request.path == "/" or request.path == "index.html":
      sp = get_object_or_404(staticpages, relative_page_url__exact="./index/")
   else:
      sp = get_object_or_404(staticpages, relative_page_url__exact=".%s" % request.path.replace("index.html",""))

   # low level cache
   key = "sample_static_%s_%s" % ( sp.id, sp.revision)
   content = cache.get(key)
   if content == None:
      content = sp.content
      cache.set(key, content, 30000)

   return render_to_response(template, {
      'title':sp.page_title,
      'meta':sp.meta,
      'js':javascript(request),
      'searchbar':searchbar(request),
      'crumbsbar':crumbsbar(request),
      'content':content,
   })

Also, having the content in the database allowed me easily to re-write the search engine. Good URL's do not change so I have things like "specifics/list.html" in the database.

For migration, I wrote a quick script to recursively grab the content from the static site and put it in PostgreSQL table created with Django.

The low-level cache (See the cache.get() method above) I added to speed up for these static pieces. I am so amazed how much faster these pages are being served. Even though they are now being pulled in from a database they are now faster than when they were being served as static content from a large web hosting agency. This is true with and without the cache. In concept the cache should be faster. Although I am having a hard time detecting the difference. I tried "file" and "memcache" methods. I am afraid this site is not the sort to be slashdoted, so I guess I need not concern myself too much.

btw, I used a Python framework called funkload to conduct load tests on Django. Seems fairly cool but a little bit overkill for what I need to test. Maybe simple webunit (I did not try) would have been easier.

Django is fast. Fast is setting up. Fast for fitting in with legacy item. And these pages load really fast. Not only faster than most JAVA and RoR sites, but faster than many static sites.

My re-introduction into the web programming world is well under way. After careful evaluation on various web-programming frameworks, I have decided to start with Django for some serious contract work I am currently bidding on. Hence, I am now a Django developer--see the new Django section in this blog.

In the past, I have tried to stay away from web-work. The reason I venture to bid on such work is that the potential client is highly integrated with many types of media. My goal is to fulfill some very complicated tasks where many systems are are married with a web interface only being the tip of the iceberg. The only reason I stay away from some web-work is that it has been saturated with quite a few programmers who concentrate very little on good programming techniques, development philosophies, and quality assurance. I have said this before, but I still believe good programming and simply building a one-off website have very little in common.

Moving forward with my emphasis on sound techniques, I make specific reference to the MVC (Model View Controller) architecture used by Django. Taking it a step further, I broke these up into Roles:

• Role 1 Model) Highly Relational Database
• Role 2 View) Graphic Design of Reports, Forms, and Web Templates
• Role 3 Controller) Event Driven Dynamic Content Programming

And I needed to add some roles to the Administrative Side:

• Role 4 Hosting) System Administration, Security Management, and Backups
• Role 5 Administration) Data Entry, User Accounts

Roles 1-3, have separate hourly rates. Role 4, is a monthly rate. And Role 5 is handled by the client thanks to Django's Admin. interface which comes for free.

My MVC representation does not necessarily reflect MVC in the programming world 1-to-1. I simply present this abstraction as a way to break up the work into some business worthy logic. Furthermore, I can easily hand over pieces of these roles to different parties if it simply becomes too-much. So, Role 1 is the database programmer (or in Django, the person who builds the models), Role 2 is the Graphic Designer the person who builds the templates (not really the Views used in Django), and Role 3 is the person who writes the actual business logic in the views. It's best that Role 1 knows PostgreSQL and Python fairly well. The Role 2 person must know CSS, HTML, some Javascript/AJAX and general good design skills for template building. Role 3 should know Python and be proficient in all other areas because they will be the primary programmer who glues it all together.

For now, I am roles 1-4. Nevertheless, despite my butchering of MVC for business reasons, the real importance with my choice of Django over others is it's ability to be agile. "Agile" is term generally understood by business people and programmers, alike, regardless in how this is achieved.