I’ve been asked a couple of times recently, as part of separate projects, to split the results of a SQL query on whitespace within. Simply put, how does one go from:
foo
foo bar
quux
blort wuu spong
to the expanded form:
foo
foo
bar
quux
blort
wuu
spong
If your web application ensures that all your incoming CGI variables are free of the most common source of malicious site damage, can you stop worrying?
Sick and tired of getting a million hits, all to the same page, which more often than not hasn’t been updated in the mean time? Want to reduce your bandwidth and server-time loads without necessarily impairing your visitors’ experience of your site?
Coming to the end of the Drupal project on which I’m currently working, I spotted someone else’s brand new site on drupal.org: TeamSugar.
CCK is Drupal’s way of making rich content. It means that nodes of any content type can have any kind of data attached to them, so you can have e.g. a directory of superstore outlets, where the outlet records have their longitude and latitude (editable by a Google Map widget) whereas the contact records (e.g. Sales Manager, South-East) can have a portrait photo, selected from an image gallery in a dropdown widget. (A note on terminology: widgets are the structures which are used to edit the CCK data, typically defined in the same CCK submodule as the data types).
FixMyStreet is getting some great press, this time a Guardian article comparing it favourably to Facebook.
The LAMP-stack community frequently shows their disdain for foreign and primary keys in databases, and sometimes with reason borne of experience. MySQL historically has been little more than a nice language for comparing a set of unrelated spreadsheets, so referential integrity has had to happen at the application layer or not at all. As such, careful MySQL users put a lot of work into ensuring referential integrity, without the help of the database.
Following on from Simon Willison’s recent post about Django’s ORM, I’ve found both the lazy evaluation and chaining properties of Django’s querysets to be really useful quite deep within Django’s own view-layer framework.
Django’s templating language is intentionally quite restrictive. The idea is that you have to do all your data munging in the control-ish sublayer of the view layer, in the method registered as handling the view in urls.py. In principle this simplifies templates, but in practice it can make life for the developer more difficult: you have to really think ahead, and assemble your variables properly, so that the templating language can use simple iterative loops to prepare your HTML.