I wanted to have the possibility to use a wiki-like markup style in my flatpages for various purposes (embedding images, quoting, etc.)
After a few dead ends I came up with this, which is quite nice I think.
> It basically takes a named tag, loads the corresponding template, passes in all arguments, renders the template and replaces the named tag with the result.
*The markup looks like this:*
> [[example:value to pass|option1=somevalue option2=values can have spaces too! without having to put them in quotes option3=some other value]]
*This results in:*
* Filter tries to load wiki/wiki_example.html
* If it is loaded, it passes an WikiElement containing the value and the options to the template, renders it and replaces the tag with the rendered template
*In the "wiki/wiki_example.html" template you can use it like this:*
{{param.value}}
{{param.opts.option1}}
Or loop over param.opts.iteritems.
- template
- filter
- markup
- wiki
One of the things about Django that has always irked me is that there seems to be no standard facility for just loading a page and displaying it, simply. Yes, there is the flatpages module, but it is primarily designed for loading content from a DB. While you specify a custom template and put in junk values for the DB content, it just feels like extra, unnecessary work.
Thinking about the problem some more, I borrowed from the idea of flatpages and implemented a view that will load an otherwise unmapped template off the filesystem and render it. This is very useful when converting an existing site over. Just copy your files over. No need to map anything in the URL conf or use the admin to add any flatpage entries. Since it'll render the template, too, you can even use tags and what not, so it need not be a static page.
I wanted to make the objects of a particular model approvable and store the timestamp of when that happened. In other frameworks/languages, I used to combined those in one "approved_at" field, which would be NULL if an object was currently unapproved.
I tried different approaches to implement this in django, and this is the best I came up with so far. Basically, the code in __setattr__ makes sure that the field, once set, will not be updated again.
Overriding setattr__() could also be a solution to determining if a field value has changed in save(), a question that seems come up from time to time in #django.
- newforms
- models
- fields
- forms
- save