OT: Website CMS

[CLIFFORD ILKAY]

On 24/08/09 11:09 PM, Rajinder Yadav wrote:
> Thanks William, I was thinking this might be the case about
> indentation and my (silly) bias. Unfortunately I have seen too many
> bad C/C++ code that has been well indented yet has too many nesting to
> make it readable.


Don't extrapolate from your bad C/C++ experiences to Python. For some
reason, I don't recall "too many nesting" as being a problem in Python.
I just haven't seen it.


> Also with many IDEs one can jump to the start and end of a code block,
> since the IDE can match braces. I don't see how this is possible with
> Python style code? If I am writing my own code, or the blocks are
> small or not nested than I have no issues, but from my experience this
> is not always the case.


It takes a lot less code to do things in Python than it does in C or C++
so you don't have as much code in which to have to jump around. Besides,
any editor that understands Python can do code folding.


> If I am going to inspect and use community code, I don't want poorly
> factored nested code to get in my way. I think that is my bigger
> concern.
> 
> I guess this is one of those (personal) things when you get over it
> you get over it, but I am not there =) .... maybe I need to look at
> some production python code to convince myself and not let something
> like this get in the way of using a (possibly) good framework.


from django.db import models

class Page(models.Model):
    name = models.CharField(max_length=100, unique=True)
    slug = models.SlugField('Friendly URL', unique=True)
    sort_order = models.IntegerField(default=0)
    keywords = models.TextField(max_length=255, blank=True, null=True)
    content = models.TextField(blank=True, null=True)

That is actual code from a working site from an app we called "cms".
(Gee, I wonder what it does? :) In Django, it all centers around the
"model". Above, we're declaring a Page class which has a few attributes.
We'd need a database connection string which "python manage.py syncdb"
will use to generate the database objects based upon the model above.
That will create a database table called "page" with columns "id, name,
slug, sort_order, keywords, content". Unless you specify otherwise, it
will create an "id" column as the primary key. The effect of the
"unique", "max_length", and "null" attributes on the database should be
obvious. The effect of "blank=true" is on the auto-generated CRUD
(Create, Read, Update, Delete) forms in the admin interface.

To turn that into a complete web site, we would need some way of
dispatching URL requests to a function that fetches the appropriate
pages from the database and passes the results onto a page template. The
URL dispatching can be done via regular expression like this:

(r'^$', 'get_page', {'page_name': 'Home'}),
(r'^blog/$', 'get_page', {'page_name': 'Blog'}),
(r'^contact/$', 'get_page', {'page_name': 'Contact'}),

"get_page" is a function to which we pass a dictionary with the page
name and it looks something like this:

def get_page(request, page_name):
  the_page = Page.objects.get(name=page_name)
  return render_to_response('myapp/a_page.html', {'the_page': the_page})

That function is doing the equivalent of "select * from page where
page.name = page_name" where page_name was passed as a parameter to the
function from the URL dispatcher and it passes the result, i.e. the_page
object, to a page template called "a_page.html". In most Django apps,
the ORM (Object Relational Mapper) is sufficient. If you need to use raw
SQL for performance or cases where the ORM doesn't have a good (or any)
way of doing expressing your query, you can easily do it.

Let's look at the page template now.

{% extends "base.html" %}
{% block content_area %}
  <div class="main-content">
  {% if the_page.content %}
    {{the_page.content}}
  {% else %}
    <p>No page content available.</p>
  {% endif %}
  </div>
{% endblock %}

The first line is an example of template inheritance. "base.html" is the
base page template that has the common page elements for the entire
site. We'll look at that in a moment. The things enclosed within a pair
of curly braces and a per cent sign are template tags. The things
enclosed within a pair of curly braces are variables. If we hit the
"Contact" page, as long as something is returned by the "get_page"
function, it will be passed to our template. Let's look at the content
of "base.html" now.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
usual stuff that goes in the head section - could (and do) use
templating here too
</head>

<body>
Page Banner markup goes here
Navbar markup goes here
{% block content_area %}
{% endblock %}
Footer markup goes here
</body>
</html>

Everywhere you see "something goes here", you can use templating too,
and we do but for the sake of this example, it's not important. The
important bit is the content_area block tag. On base.html, it's empty.
In a_page.html, it's populated by page.content. On some other page, say
product_listing.html, it could have a list of products.

Obviously, all of the above is excerpted and simplified for the sake of
brevity.

What I just described above is arguably a "CMS". It took a trivial
amount of code to create. How the rendered output of a_page.html looks
and whether you use fancy Javascript or not is entirely up to you. You
style it with CSS and if you want to use Javascript, pick your favourite
library and use it. You have highly-functional CRUD forms that are
auto-generated from which you can now enter page content. At the moment,
you'd have to enter markup into the "content" field but it's pretty easy
to add your choice of a Javascript rich-text editor to forms.

Note that you will never see "a_page.html" anywhere in the URL. That's
just an internal name for one of the page templates we have. We use the
.html extension so that you can open and edit the file using whatever
HTML editor you use. People have created Textmate bundles for Django
tags. I have created the equivalent in Quanta, though I don't really use
them as much as I thought I would.


> Thanks for sharing your similar experience, I am sure I am not the 1st
> or last developer to have this gripe about python.


Those that get past the "I love curly braces" stage of denial eventually
go on to love Python. :)
-- 
Regards,

Clifford Ilkay
Dinamis
1419-3266 Yonge St.
Toronto, ON
Canada  M4N 3P6

<http://dinamis.com>
+1 416-410-3326
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists