28 Jan 09 Blueprint CSS Framework
I downloaded the Blueprint CSS framework and checked out the docs and read the source files. Wow, this was easier than I thought. My concerns and confusion about getting some decent initial CSS for the site just evaporated. After about 15 minutes of reading and playing around I had something that was better than I had ever come up with before. And since CSS “cascades”, it will be very easy to customize the default styles and typography. I highly recommend using a CSS framework if CSS isn’t your strength and/or you need to do quick prototyping. Thanks Blueprints CSS, this is exactly what I needed!
Tags: blueprints, css
25 Jan 09 Displaying a Page’s SQL Queries
I’ve been meaning to start paying attention to the SQL queries that Django is generating for me. I’d like to know if there are any dumb things I am doing. And down the road I am going to start employing low-level caching, and seeing what queries I am doing will help me decide what things to cache. I finally broke down and figured out how you can display the SQL queries used during an HTTP request on the rendered web page. Django makes this quite easy and it is fully documented.
If your TEMPLATE_CONTEXT_PROCESSORS in your settings.py file contains “django.core.context_processors.debug”, and DEBUG is set to True, you have access to a variable in your templates called sql_queries. This is an ordered list of {'sql': ..., 'time': ...} dictionaries that represent every SQL query and how long each one took during the processing of the request.
It was quite easy to add the following to the very bottom of my site’s base template:
{% if debug %}
<div id="debug">
<ol>
{% for s in sql_queries %}
<li>{{ s.sql }} : <b>({{ s.time }})</b></li>
{% endfor %}
</ol>
</div>
{% endif %}
Now I can keep an eye on what’s happening at the database level. I’ve already added a few key “select_related” clauses to some of my Django ORM queries that have saved 10-30% on the number of trips to the database per page. Cool!
20 Jan 09 Weekend Coding Wrapup
I sat down and pounded out quite a bit of code last weekend, which is kind of unusual. I want to summarize what happened and leave some notes for myself.
On the comments front, I worked commenting into both the news and polls applications. This was astonishingly easy as I had already done the work once for the photo of the day. Django’s content types framework is really nice. Having the ability to attach comments to arbitrary models is just brilliant.
It occurred to me that I should take advantage of Django forms media, and then I wouldn’t have to repeat the several lines of <link> and <script> tags I have to add to every page that uses the markItUp! editor. I added a “get_comment_form for” template tag, and then I thought I could just do a “{{ form.media }}” at the top of the template and then use the same form variable at the bottom of the template. But this did not work. I believe it has something to do with using the form variable in separate blocks in my templates that extend my base template. I posted a question about this on the django-user’s list, but did not receive a response. Oh well, not a huge deal, but I must investigate why this didn’t work sometime.
The other weird thing that happened was my Firefox browser started lurching to a halt when the shoutbox was being displayed with my new CSS scheme. I swear it didn’t do this before with the older CSS. So I got mad and disabled the Javascript scrolling for now, leaving it with a scroll bar (which actually doesn’t look that bad to me). I think this is only a problem on the Linux Firefox, I have not seen this on Windows. I have noticed that some sites give Linux Firefox some trouble if they have Javascript. It seems to eat an inordinate amount of CPU, making things like paging up and down a chore. I started looking at some jQuery-based tutorials for an alternate means for scrolling but didn’t find anything that jumped out at me right away. Again, I’ll put that on the to-do list.
On the CSS front, I came across the Blueprint CSS framework. This looks interesting for a design dolt like myself. It may help me with the overall site structure.
And finally last night I started working on the downloads application. This is my last “easy” application. After that I have to work on the calendar, the member map, Paypal, and the forums. The downloads application will be very similar to the Web links application that I did early on. It will contain many of the same types of views and sorting options. I am going to try and do it a bit smarter this time as I have learned a lot since then. I want to add an AJAX style star rating system and comments. I may then go back and refactor Web links with what I have learned. Ideally I should be looking for ways to share the code. If Django had a class-based way of handling views I think I could see a way forward. I could also finally break down and investigate generic views.
16 Jan 09 CSS problems at bay for now…
I reworked the CSS on the test site by following this Jina Bolton tutorial at Sitepoint. My crazy div problem disappeared, which was my main goal. I consider this an interim step. I need something that looks like a semi-realistic website while I am developing. It helps me visualize what I am doing. I decided to leave the colors in the tutorial as-is rather than spend a lot of time tweaking them. Again, this is just a framework to get me going further. Hopefully I can enlist some of the folks on SG101 to assist with the final CSS and design.
The tutorial was very good. Since I’m not a designer, it was interesting to read how a good one works. And I learned a few things about CSS that should really help me in the future.
Speaking of cool CSS tricks, I found this tuturial on the web over lunch today. It is making me re-think how to markup the comments on my site. Semantically, perhaps I should display them as a list of blockquotes. Very interesting stuff!
Here is a screenshot of the test site with the borrowed CSS design.
10 Jan 09 Experimenting with mod_wsgi
I’m getting a bit closer to wanting to deploy some of the work I have done on the new site in order to get feedback and find bugs. I’ve already got The Madeira’s site running under mod_python, and it seems like a bit of a pain to get another site running under mod_python. Or, I should say, I don’t fully understand how to do it. 
First a bit of background on the server I am renting. It is running Fedora Core 6 and has Plesk installed. Plesk is a web-based application that manages the server for you. I click around in it to add domains, sub-domains, configure the mail service, etc. Plesk auto-generates the apache configuration files based on your settings.
I’ve been reading good things about an alternate way to deply Python web applications: mod_wsgi. So a couple of days ago I decided to try it out. Here is a quick sketch of what happened.
It was easy enough to grab the source and to do the usual “make” and “make install” to build it. However, I did notice right away that (via Graham Dumpleton’s excellent documentation) that the mod_wsgi.so module was linking against the static version of my Python library instead of the dynamic one. Of course if I am going to have multiple processes running a Python interpreter, I am going to want them to share the code to avoid bloat. I did some poking around on my server and found the correct Python shared library, and I put a symlink to it inside my python/config directory. Completely rebuilding mod_wsgi at that point seemed to resolve that issue.
I then configured a subdirectory on the virtual host running this site to be served by the sample wsgi application. This worked straight away when mod_wsgi was configured to run in embedded mode. However the real goal is to run in daemon mode, in which separate processes are launched to run the application, and apache defers to them. You can also run these processes as a different user than apache for added security.
When I configured mod_wsgi for daemon mode I ran into problems. Fortunately I received excellent help from Graham Dumpleton on the mod_wsgi user’s list. First of all I was still running mod_python, and this was probably still using the static Python library. I temporarily disabled it and Graham had me change the apache log level and examine the logs. For whatever reason, the WSGI daemon processes were not inheriting the apache user and group, instead they were using -1/-1 for uid/gid. When I added configuration settings to explicitly set the user and group for these WSGI processes to run under, everything was fine (if mod_python was out of the picture that is).
After a bit of closer examination, it turns out that in my main http.conf file I have this:
Include conf.d/*.conf User apache Group apache
So for whatever reason, user and group ID’s were not set when my conf.d/mod_wsgi.conf file was being processed.
So now I am poised to cut The Madeira site over to mod_wsgi and retire mod_python. I can then more easily create a new process to run a test site for SG101 2.0.
While I have no real runtime experience with mod_wsgi yet, I am still very impressed with the project and Graham Dumpleton’s extensive documentation and knowledge of apache.
01 Jan 09 Comments
Happy New Year!
I spent a fair amount of time googling and studying blogs of other people on what they had done to get the Django comments application to work smoother for registered users. I also looked at the django-threadedcomments application a bit. It seems very good, I just don’t like threaded comments. Then I started looking at the source code to the Django comments application and seeing that there wasn’t a lot of magic going on. In other words, even I could sort of understand what was happening. So I started to write my own comments system, tailoring it to my requirements. At first I thought this would be a ton of work, especially the template tags. However Django really makes this kind of stuff easy, and I am really learning a lot about how Django works by undertaking this. So any trepidation I felt at first is gone. I am having a lot of fun and learning a lot. I am keeping my template tags the same as the contributed comments app, so in case Django 1.1 has a much nicer system I can easily cut over to it. Learning about the Content Types framework and more about template tags has made this exercise very worthwhile for me.
I intend on supporting both a traditional comment post and an AJAX style post. Once I get some more stuff working I will investigate using Markdown and markItUp! editor I mentioned in my last post.
14 Jan 09 Update on Comments and CSS Woes
I’ve made good progress on the comments system, and I’m glad I took the time to roll my own. I have a nice AJAX style commenting system integrated with the markItUp! editor. I’m allowing comments to be marked up with Markdown, and I’m very happy with it. Having the ability for users to easily post links and images will be a big improvement from the existing site’s commenting systems. I need to cut the private messages application over to markItUp instead of TinyMCE. I think TinyMCE is a bit overkill for anything except news stories. I also added the ability for users to “flag” comments for spam or abuse.
The markItUp editor is very nice, and I was even able to add a drop-down menu for my smiley system. Now one can click on a smiley from the editor and get it added to the comment! The markItUp editor has a slick preview system, which can use AJAX to post what the user has typed so far and get an HTML response. The only drawback is I can’t easily clear or hide the preview pane once the comment has been posted by AJAX. So you are left with a blank editor ready for the next comment, but the preview pane is still showing whatever you previewed last. This is minor, I think, and I’ve already made the author aware of this issue. He told me he will look into it for the next release. I highly recommend markItUp.
And finally I took a cue from Malcom Tredinnick’s blog (the Django source is available for study – Thanks Malcom!). I added a field to the comments table to store the rendered HTML for each comment. This field is updated on each comment object’s save. This will save processing time to convert the Markdown markup to HTML. Since comments are viewed many, many times compared to how often they are edited, this seemed like a sensible optimization at the expense of some disk space.
I need to add comments to the other parts of the system I have developed already (news, polls, etc.). However I’m being distracted at the moment by a problem I am having with CSS. This has been bugging me for months now. I don’t know why it happens, but I’m seeing <div> tags in a left floating <div> affect <div> tags in my main content area. Large gaps get created. It seems that I may be trying too hard to duplicate the PHP-Nuke blocks, and nesting lots of divs seems to be very fragile. I think I might have to investigate a different CSS layout and redo my base template. I’m googling various CSS layout tutorials in my spare time. I don’t want to become an expert in this, but I need something simple that looks decent. I wish I had a web designer to help me out with this part.
Tags: comments, css, markitup, sg101