Personal tools
You are here: Home Weblog
Document Actions
  • Send this page to somebody
  • Print this page
  • Add Bookmarklet

Weblog

2012-01-16

A simple epub file renaming utility

Filed Under:

I have a couple of epub files that have random names assigned to them, and I wanted to rename them based on their metadata, in the form Author - Title. Below is what I came up with:

#!/usr/bin/python

from zipfile import ZipFile
import lxml.etree
import os.path
import shutil
import sys

namespaces = {
        'u':"urn:oasis:names:tc:opendocument:xmlns:container",
        'xsi':"http://www.w3.org/2001/XMLSchema-instance",
        'opf':"http://www.idpf.org/2007/opf", 
        'dcterms':"http://purl.org/dc/terms/",
        'calibre':"http://calibre.kovidgoyal.net/2009/metadata",
        'dc':"http://purl.org/dc/elements/1.1/",
        }

def main():
    if len(sys.argv) != 2:
        print "Need a path."
        sys.exit(1)

    fpath = sys.argv[1]
    zip = ZipFile(fpath)
    meta = zip.read("META-INF/container.xml")
    e = lxml.etree.fromstring(meta)
    rootfile = e.xpath("/u:container/u:rootfiles/u:rootfile", 
            namespaces=namespaces)[0]
    path = rootfile.get('full-path')
    opf = zip.read(path)
    e = lxml.etree.fromstring(opf)
    title = e.xpath("//dc:title", namespaces=namespaces)[0].text
    author = e.xpath("//dc:creator", namespaces=namespaces)[0].text


    base = os.path.dirname(fpath)
    new_name = "%s - %s.epub" % (author, title)
    shutil.move(fpath, os.path.join(base, new_name))

if __name__ == "__main__":
    main()

2011-06-28

Getting the superclasses for a python object

Filed Under:

Zope 2 (and Plone) persistent objects usually have an intricate inheritance tree. Finding what classes an object inherits can be a time consuming task, hunting through the various eggs for the relevant source code. Below is a little snippet that shows how to easily get the list of superclasses:

(Pdb) pp type(ff).mro()
(<class 'plone.app.blob.subtypes.image.ExtensionBlobField'>,
 <class 'archetypes.schemaextender.field.TranslatableExtensionField'>,
 <class 'archetypes.schemaextender.field.BaseExtensionField'>,
 <class 'plone.app.blob.field.BlobField'>,
 <class 'Products.Archetypes.Field.ObjectField'>,
 <class 'Products.Archetypes.Field.Field'>,
 <class 'Products.Archetypes.Layer.DefaultLayerContainer'>,
 <class 'plone.app.blob.mixins.ImageFieldMixin'>,
 <class 'Products.Archetypes.Field.ImageField'>,
 <class 'Products.Archetypes.Field.FileField'>,
 <type 'ExtensionClass.Base'>,
 <type 'object'>)

 Credit goes to the original post where I found this.

2011-05-02

Version conflict: zc.buildout's version of madness

Filed Under:

I'm not even trying to understand what happens, because it's aggravating to see buildouts fail like this:

While:
  Installing.
  Getting section zope2.
  Initializing section zope2.
  Installing recipe plone.recipe.zope2install.
Error: There is a version conflict.
We already have: setuptools 0.6c9

or, worse, this:

While:
  Installing.
  Getting section zope2.
  Initializing section zope2.
  Installing recipe plone.recipe.zope2install.
Error: There is a version conflict.
We already have: zc.buildout 1.5.2

Well, technically I know what happens: for example, zc.buildout is latest 2.0a1 now, but I've already installed 1.5.2 in my virtualenv (the bootstrap process failed hard, there are a tons of bugs there, I've had more failures in bootstrap then success, lately) and I had one product in my buildout which depended on zc.buildout, so it tried to pull the latest, only to get a version conflict.

I wish zc.buildout would behave more inteligently. Even specifying 

prefer-final = true

didn't do much to solve my problems. The only way to solve the problem was to add the following to the buildout.cfg file:

[buildout]
...
versions = versions

[versions]
zc.buildout =1.5.2
setuptools = 0.6c9

UPDATE: a better solution is to have:

[versions]
zc.buildout =
setuptools =

2011-05-01

Building PIL with JPEG support on Ubuntu 11.04

Filed Under:

I had problems building PIL with jpeg support on the latest Ubuntu. There are now two libjpeg libraries: one called libjpeg62 and one libjpeg8. Every guide on the net explaining how to compile PIL with jpeg support points to installing libjpeg62-dev. Needless to say, libjpeg8-dev is actually needed to properly build PIL. My reason for initially avoiding libjpeg8 is that it causes libsdlimage-dev to be uninstalled, so it looks like I'll have to juggle packages whenever I want to compile something that requires SDL.

2011-03-09

Export/import users in and out of Plone

Filed Under:

A dirty quick method of importing and exporting the users (only usernames and passwords) out of Plone, using 2 external methods. Code below, not much else to say.

import cPickle

def export(self):
    pas = self.acl_users
    users = pas.source_users
    passwords = users._user_passwords
    result = dict(passwords)

    f = open('/tmp/out.blob', 'w')
    cPickle.dump(result, f)
    f.close()

    return "done"

def import_users(self):
    pas = self.acl_users
    users = pas.source_users
    f = open('/tmp/out.blob')
    res = cPickle.load(f)
    f.close()

    for uid, pwd in res.items():
        users.addUser(uid, uid, pwd)

    return "done"


2011-02-08

Set product configuration globally in zope.conf

Filed Under:

I have a Zope product that needs to write in a centralized location, across multiple instances. The classic Python solution would be to write a variable in a config.py module and read that location from the code, but this feels unelegant in an environment that uses zc.buildout for deployment. The solution I have found is, as follows:

In buildout.cfg, in the instance part definition, add:

zope-conf-additional =
    <environment>
        mylocation ${buildout:directory}/var/mylocation
    </environment>

Next, inside the product code I have:

from App.config import getConfiguration
import os

conf = getConfiguration()
dest = conf.environment['mylocation']
if not os.path.exists(dest):
    os.mkdir(dest)

There were 2 things that I had to research for this task: reading the global zope configuration (that's done with App.config.getConfiguration()) and the fact that you can't add arbitrary key/values in zope.conf and have to use the <environment> section.

2011-01-04

Running Products.Gloworm on Plone 4

Filed Under:

For some reason, the TTW developer tools tend to get neglected in the Plone world. A valuable tools such as Clouseau has fallen out of favour and now Gloworm, the @@manage-viewlets replacement/complement won't run in Plone 4 (at least at version 1.0, which is the latest right now on PyPI).

Fortunately, Gloworm has been updated in svn trunk. To get the latest version you need to add it to sources (in buildout.cfg or develop.cfg):

[buildout]
eggs +=
     Products.Gloworm

[sources]
Products.Gloworm = svn https://weblion.psu.edu/svn/weblion/weblion/Products.Gloworm/trunk/

Next, run in the shell:

#bin/develop co Products.Gloworm
#bin/develop rb

2011-01-02

A pattern for programatically creating Plone content

Filed Under:

I'm importing content from a legacy system to a new website that I'm doing with Plone 4 (wow! what an improvement, in speed and technology) and was looking at the existing documentation on how to programatically create new Plone content. The issue I'm having with the existing documentation is that it's incomplete. It won't give you automatically created ids, you'll have to manually call mutators if you don't know any better, etc.

This is what I have come up with (this code runs in a browser view):

_id = self.context.generateUniqueId("Document")
_id = self.context.invokeFactory(type_name=type_name, id=_id)
ob = self.context[_id]
ob.edit(
     description = "text...",
     subject     = ('tag1', 'tag2'),
     title       = "some title...",
 )
ob._renameAfterCreation(check_auto_id=True)
_id = ob.getId()

One thing I notice is that Plone 4 starts faster, comes with easily pluggable developer tools, and in general feels a lot more polished then any previous Plone releases. It's a good system to work with.

2010-09-19

A miniguide to Dolmen packages

Filed Under:

I'm finally starting a long-overdue project which I have decided to do with Dolmen. As usual, I start by studying its source code and the packages that are available for it. By itself it can will get me about 60% with the requirements for my project, so it's a pretty good starting base. I plan to also study and use some of the menhir.* packages, which are pretty good as generic CMS content types.

dolmen
Dolmen is an application development framework based on Grok and ZTK which also provides a CMS (Content Management System) out of the box. Dolmen is being made with four main objectives in mind: easily pluggable, rock solid and fast content type development, readability and speed.
dolmen.app.authentication
Users and group management in Dolmen
dolmen.app.breadcrumbs
Provides a breadcrumbs navigation for the Dolmen applications. It registers a viewlet to render the links.
dolmen.app.clipboard
Provides a useable "clipboard", that allows you to cut, copy and paste your objects.
dolmen.app.container
Is a collection of tools to work with containers in Dolmen applications.
dolmen.app.content
Provides out-of-the-box utilities for Dolmen applications content.
dolmen.app.layout
Provides ready-to-use components to get a fully functional and extensively pluggable User Interface for a Dolmen application
dolmen.app.metadatas
Forms and viewlets to edit ZopeDublinCore metadata
dolmen.app.search
Viewlets and utilities for permission-aware searching of objects in a Dolmen site.
dolmen.app.security
Roles and permissions for a Dolmen site
dolmen.app.site
The basic Dolmen objects that serve as roots of Dolmen sites
dolmen.app.viewselector
Allows basic management of alternate views
dolmen.authentication
Basic components for authentication
dolmen.beaker
Zope sessions implementation using beaker
dolmen.blob
A layer above zope.file using ZODB blobs as a storage facility. It offers a BlobFile content type and a BlobProperty property for complex schemas.
dolmen.builtins
A set of interfaces that apply to basic Python types, to better integrate them with ZCA
dolmen.content
Base classes and utilities to create content types
dolmen.field
Additional fields usable in schemas. At this moment there's just GlobalClass
dolmen.file
Allows you to manage and store files within the ZODB. It takes the core functionalities of zope.app.file, and simplifies them, using Grok for views and adapters registrations.
dolmen.forms.base
A package in charge of providing basic functionalities to work with zeam.form Forms.
dolmen.forms.crud
A package which helps developers create their C.R.U.D forms using Grok, zeam.form and dolmen.content. It provides a collection of base classes to add, edit, and access content. It innovates by providing adapters to customize the fields of a form.
dolmen.menu
Aims to provide the most flexible and explicit way to create and manage menus and their entries with Grok.
dolmen.queue
A simple layer on top of zc.async to provide queuing of tasks. Not ready?
dolmen.relations
Is a thin layer above zc.relation, allowing a simple and straightforward implementation of standalone relationships between objects.
dolmen.storage
Defines a clear high-level API to deal with pluggable storage components.
dolmen.thumbnailer
Is package specialized in Thumbnail generation. Using the dolmen.storage mechanisms, it allows a pluggable and flexible thumbnail storage.
dolmen.widget.file
A package that walks hand-in-hand with dolmen.file. It provides a useable and pluggable way to render the dolmen.file.FileField in a zeam.form Form.
dolmen.widget.image
A thin layer above dolmen.widget.file providing a widget suitable to fields implementing IImageField. It adds, thanks to dolmen.thumbnailer a preview of the uploaded image in both input and display mode.
dolmen.widget.tinymce
A package that provides a useable and pluggable way to render a text field as a WYSIWG editor in a zeam.form Form.
dolmen.workflow
Nothing here
megrok.icon
Allows registration of icons and associating them with content types
megrok.resourcemerger
Allows concatanation and packing of browser resources (css and js)
menhir.contenttype.document
An example document content type
menhir.contenttype.file
An example file content type
menhir.contenttype.folder
An example folder content type
menhir.contenttype.image
An example image content type
menhir.contenttype.photoalbum
An example photoalbum content type
menhir.contenttype.rstdocument
An example rstdocument content type
menhir.contenttype.user
An example user content type
menhir.library.tablesorter
Registers a jquery based library for HTML tables sorting
menhir.simple.comments
Simple commenting system with avatar integration
menhir.simple.livesearch
A viewlet that provides a livesearch box
menhir.simple.navtree
A viewlet providing a navigation tree
menhir.simple.tag
A tagging engine based on the lovely.tag
menhir.skin.lightblue
A complete skin for a Dolmen site.
menhir.skin.snappy
A skin for Snappy sites
snappy.site
The Snappy, a video sharing sample site
snappy.transform
Mimetype transform utilities. Not finished?
snappy.video.flasher
Utilities to mark files as Flash and allow to view them.
snappy.video.player
A video player for flash movies
snappy.video.transforms
Convert video files to flash movies and thumbnails
zeam.form.base
A form library designed to be grokish and simple
zeam.form.ztk
zope.schema integration for zeam.form. It provides widgets and default CRUD style actions.
dolmen-documentation
A few tutorials for Dolmen
dolmenproject
A Paste script extension that allows quick bootstrapping of new Dolmen projects

To download all the packages, I've ctrl+selected the git repositories names from http://gitweb.dolmen-project.org/, pasted them into a repositories.txt file and ran the following script:

 

import subprocess
import os

f = open('repositories.txt')
for line in f.readlines():
    git = line.strip()
    pkg = git
    if pkg.endswith('.git'):
        pkg = ".".join(pkg.split('.')[:-1])

    if os.path.exists(pkg):
        subprocess.check_call(['git', 'pull'], cwd=pkg)
    else:
        subprocess.check_call(['git', 'clone', 'git://devel.dolmen-project.org/' + git])

 


2010-08-22

Migrating content (folders) from Plone 3 to Plone 4 via zexp import

Filed Under:

I had a need (and a problem) moving some content from a Zope 2.10/ Plone 3.3 instance to a Zope 2.12/Plone 4 instance. The path I have chosen was that of the least resistence, which for me was exporting the folder I was interested as a zexp file from the old instance and importing it in the new Plone instance. According to some members of the #plone IRC channel, this method of getting content from one zope instance to another is not possible, or at least not supported. I supposed that's correct, zexp import works best for moving content between identical zope instances, but, as they say, necessity is the mother of learning.

The issue is that the implementation of folders has changed from Plone 3 to 4 to use BTrees, which greatly improves performance. The problem is that, when viewing imported folders, I got the following traceback:

Traceback (innermost last):

    * Module ZPublisher.Publish, line 116, in publish
    * Module ZPublisher.BaseRequest, line 434, in traverse
    * Module Products.CMFCore.DynamicType, line 150, in __before_publishing_traverse__
    * Module Products.CMFDynamicViewFTI.fti, line 215, in queryMethodID
    * Module Products.CMFDynamicViewFTI.fti, line 182, in defaultView
    * Module Products.CMFPlone.PloneTool, line 840, in browserDefault
    * Module Products.CMFPlone.PloneTool, line 708, in getDefaultPage
    * Module Products.CMFPlone.utils, line 81, in getDefaultPage
    * Module plone.app.layout.navigation.defaultpage, line 32, in getDefaultPage
    * Module plone.app.layout.navigation.defaultpage, line 75, in getDefaultPage
    * Module Products.BTreeFolder2.BTreeFolder2, line 337, in has_key

AttributeError: 'NoneType' object has no attribute 'has_key' 

The solution was to call @@migrate-btrees on the imported folder, which fixes that folder and makes it conform to the latest implementation.

One final note, the default Plone buildout doesn't have a folder called "import" anywhere in the buildout, so one needs to be created inside the "client home folder", which is the folder of your plone and buildout instance, the one that hosts the bin, parts and var folders.

2010-05-12

Some issues with zc.recipe.egg's python option

Filed Under:

I've recently had to integrate a script/package into a Plone 2.5 buildout that runs on top of Python 2.4. Due to that package's dependence of a sane imaplib (and the one in Python 2.4 is buggy), I had to run the script with python2.6. To make a script run on a different python, you need to do:

[myscript]
recipe = zc.regipe.egg
eggs = 
     myegg
     IMAPClient
python = python26

The python26 option is actually the name of a buildout part that configures the python executable path

[python26]
python = /usr/bin/python26

Now the problems. I've had various buildouts fail with a message "Cannot find egg myegg". After a bit of effort, we managed to trace the cause to this problem:

First, the python path in the [python26] part was incorect. Second, even if it pointed to the proper binary, the -devel packages for that python needed to be installed.

Well, now I know. Hopefully I'll remember it for the next time when I'll encounter the problem.

2010-02-25

Can you do this on your shiny Mac?

Filed Under:

Probably you can, but you have never done it because you have a shiny interface for everything. I'm talking about this discovery of mine:

svn diff | kompare -

What it does is to take the output from svn diff and pipe it into Kompare, a merge/diff utility from the KDE Project. I can do this from the command line, straight from the directory that I'm in, and bang! I get a nice graphical overview, complete with the tree structure that I can navigate to see what I'm about to commit. Honestly, this little command gets me excited everytime I run it.

2010-02-24

Generating products outside of the Products.* namespace with ArchGenXML

Filed Under:

I'm a die hard in regards to ArchGenXML usage. The number of things to know about when creating new content types for Plone is just too high. Package structure, Zope package registration, content types registration, QuickInstaller registration, GenericSetup profiles, skins registration, workflows, etc. I can go in and do changes to the code, and add to it, but generating it from scratch is a gigantic task, especially for my use case, where I need to start a new project with about 7 content types.

Now to the problem: ArchGenXML assumes (and hardcodes in its templates) the Products.* prefix for your package. I don't have any problems with it, but my employer uses a different package structure so for uniformity I need to follow their standards. 15 minutes of poking and changing through agx enabled me to change it so it would generate GS xml files with the proper namespace (based on a new model level TGV named "namespace" that I have created). After assessing the difficulty of the task and being under time pressure, I've decided to go the dumb route, which I'm documenting below:

My generation script is something like this:

./archgenxml -c archgenxml.cfg myproduct.zuml 

#rename Products.myproduct to ns.myproduct
find myproduct/* -type f -print | xargs sed -i 's/Products\.myproduct/ns\.myproduct/g'

#in the xml type profiles, replace myproduct by ns.myproduct
find myproduct/* -type f -print | xargs sed -i 's/>myproduct</>ns\.myproduct</g'

#in the profiles.zcml, rename the profile to ns.myproduct
find myproduct/* -type f -print | xargs sed -i 's/title=\"myproduct\"/title=\"ns\.myproduct\"/g'

Notice the sed lines, which change the source code to point to "ns.myproduct" instead of "Products.myproduct". Now there's just two more problems, which are actually AGX bugs:

  • the FilesystemDirectoryViews registered for the skin are incorect, so you'll need to insert this in ns/myproduct/__init__.py
from Products.CMFCore import utils
from Globals import package_home
from os.path import dirname
ppath = utils.ProductsPath
utils.ProductsPath.append(dirname(package_home(product_globals)))
DirectoryView.registerDirectory('skins', product_globals)
utils.ProductsPath = ppath
  • trying to get AGX to output the code inside a two level deep folder doesn't work (it crashes), so you'll need to move this script file and the model just above the "myproduct" folder, inside the "ns" namespace.

That's about it. Hopefully I'll find the time to fix the two bugs and add the namespace improvement in the next week. Still need to do the review for Plone for Education, which I have received for free from the publisher.

2010-01-28

Another cause for buildout failures: system distributed Python

Filed Under:

Always compile your own! One day I'll even remember that...

I've had a buildout bootstrap process failure, this time a weird one, perhaps I should document the bug and report it.

The latest Ubuntu version which I have installed (Lucid Lynx) comes with a package called python-pkg-resources, which packages pkg_resources, which used to be available only through the setuptools distribution. Buildout's bootstrap.py tries to guess if Setuptools or Distribute are installed by checking the availability of pkg_resources; by guessing wrong it all comes to a crash at the end.

I'm not very interested in debugging these types of problems anymore. Distribution/packaging tools should just work. I want to focus on my work, not debug the toolchain. No more corner cases or whatver. So I'm gonna compile separate Pythons in the future, especially when dealing with older Zope/Plones.

Dear PyPi uploaders: don't use a download URL, upload your package instead!

Pypi's biggest mistake: allowing package entries without any upload

I think this is the Python Index biggest mistake, the one which makes it unreliable for serious development environments: exposing package entries with no real package files and just a download URL. To see what I'm talking about, just examine the PyPI records for BeautifulSoup or IPython, packages that are very common in buildouts. As soon as the author and publisher of that package has a hosting problem, the developer that uses that package also has a problem. Buildouts will completely fail and this will cause dead times and frustration for the developers.

Yes, there are a couple of PyPi mirrors, but they only mirror files hosted by PyPi. The central PyPi site will probably have better performance and availability then what individual groups and developers can provide and it's always easier to mirror one single website than many, so there's no shame or loss of pride in using the PyPi to host your files. Please do so!

 

2010-01-15

Test if developer mode is set in Zope 3 and Grok

Filed Under:

I've started an application that uses Dolmen, a lightweight CMS built on top of Grok, and I want to be able to "rollup" the megrok.resource files based on the devmode setting that was set in the zope.conf file. After a bit of digging, I came up with this code that tells me the current devmode setting for the running instance:

from zope.app.applicationcontrol.applicationcontrol import applicationController
from zope.app.applicationcontrol.interfaces import IRuntimeInfo

def get_debug_mode():
    """Returns the devmode setting for a running zope instance"""

    rti = IRuntimeInfo(applicationController)
    return rti.getDeveloperMode() == "On"

 

2009-11-30

A "don't do" for internationalizing Django templates

Filed Under:

I'm internationalizing a Pinax website and I've encountered this piece of code in a template:

<input type="submit" value="{% trans "invite" %}"/>
{% blocktrans %}{{ other_user }} to be a friend.{% endblocktrans %}

The message ids for this code would be two separate blocks: "invite" and " %{other_user}s to be a friend". Both offer very little in terms of context and make the translators job difficult. Correct, in my point of view, would be the more convoluted form of:

{% blocktrans %}
<input type="submit" value="invite"/>
{{ other_user }} to be a friend.
{%  endblocktrans %}

This implies that the translators know enough HTML to notice that the value attribute needs to be translated, but the end result is a lot more flexible and provides real context to them.

TL;DR: don't split paragraphs into separate translation units. It's a NO-NO.

UPDATE: I have found what is probably the worst example of how to create a translatable template. Remember, don't assume the English language resembles anything like another language.

{% trans "edited by user" %} {{ obj.editor.username }} {% trans "at"%} {{ obj.modified|date:"H:i" }}

This should be done this way:

{% blocktrans with obj.editor.username as editor_username and obj.modified|date:"H:i" as obj_modified
edited by user {{ editor_username }} at {{ obj_modified }}
{% endblocktrans %}

Odd thing in Django: the date filter takes PHP as reference instead of Python

Filed Under:

I wonder what possible explanation there is for the behaviour of the date template filter.

Uses the same format as PHP's date() function (http://php.net/date) with some custom extensions.

I understand where Django comes from, but I think this sort of things should be more aligned with the rest of the Python world.

2009-11-18

If Django templates are an improvement over XML templates, then, by all means, please give me XML

Filed Under:

I fail to see how

{% block %} 
...
{% endblock %}

is in any way better or "less scary" then, let's say

<dj:block>
...
</dj:block>

Yet another rant, this time triggered by the error I got when writing this piece of code:

{% blocktrans with offer.offerer.username as offerer_username 
               and offer.offered_time|date as offerer_date %}
...
{% endblocktrans %}
I just wanted to split the tag on multiple lines, but it seems that's not possible. If Django templates would have been XML, then it wouldn't have been any problem formatting that piece just how I want it. Right now, the joined line takes two times the amount of my screen width.

One more thing to grudge about is that vim, even with djangohtml syntax type installed, is not very knowledgeble about how to format the template file (it treats the tags as regular piece of text). Probably this could be fixed, so I shouldn't complain about this too much.

I think Django templates are compiled to python code, so it's natural that they're treated in an imperative, dumb way, but that's not the only way of doing things. For example, Chameleon is another templating library that compiles its templates as python code, has no problem working with an XML based templating language frontends.

2009-11-17

The case against Django templates

Filed Under:

I have many grudges against the django templating language and its templates (in short, I hate them), so I'm gathering evidence to support what my "spider sense" tells me. Today the template tag system goes under fire.

Given the following template fragment:

{% load i18n %}
{% load avatar_tags %}
{% load voting_tags %}
{% load pagination_tags %}
{% load extra_voting_tags %}
{% load in_filter %}
{% load extra_tagging_tags %}
{% load sorting_tags %}

Which one is responsible for the following "anchor" tag?

{% anchor "hotness" "reddit-like hotness" %}

That's the equivalent of diving into a python module, with lots of "from X import *" at the top. Where do you find the definition of a symbol? At least, if it were Python, I could do a tag search in Vim, or a "go to definition" in Eclipse. If this practice is frowned upon in the rest of the Python world, why are so many programmers praising the Django templating system? Am I the only mad man here? My problems with this tag is that it doesn't translate the content, so I'll need to grep for its source and change it.

The template tags in Django are about extending the templating language, as to provide the programmer with new and specialized ways to interact with the template and its environment. The reason for this "tag inflation" is that the django templating language, for all its richness (by tags and filters numbers, I mean), is really limited. Python expressions are not allowed, and for every imaginable use case, there needs to be a tag, specialized or not.

How would Zope 3 solve, for example, a problem similar to the one the "anchor" tag handles? Well, rendering a special link for a content item could be as easy as

<a href="" tal:replace="someobject/@@hotness_link"><img src="hotness.gif" /></a>

Is this better? I think so. I'm editing HTML, and the <a /> tag is way better in expressing what the end result will be, compared to a simple {% anchor %} tag. Even more, the <img /> tag inside is purely cosmetic, just to cue the viewer of what the final result will be. The entire <a /> tag, with its content, will be replaced by whatever result is rendered calling the the someobject/@@hotness_link view. Finding the source of the hotness_link view is easily introspectable TTW using a debug tool such as lovely.skinbrowser.

The ZPT templates from Zope 3 can also give you a mechanism where you can add new expression types, but there's just one or two packages in the wild that define new expression types. Now compare this to the regular Django projects, were defining new tags is something that almost all projects do.

In conclusion, even though Django templates are much more imperative then ZPT, which are very declarative, they don't achieve the power and simplicity that they strive for.

Weblog
Atom
RDF
RSS 2.0
Powered by Quills
Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.
 

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: