Archive for the ‘Django’ Category

CSS Frameworks – Blueprint, 960.gs, others

Sunday, January 4th, 2009

blueprints

The Goal

We are redoing the eRacks website (our partner and suppliers of rackmount servers)  in Django, and revamping it with best-practices code and frameworks throughout – so here is the benefit of our reviews and choices for our CSS framework.

CSS frameworks are a relatively new thing in the last couple of  years, largely borne out of a need to standardize what is largely a mess or patchwork (or lack) of standards, and minor implementation differences.  Note that these are largely caused by IE (Internet Explorer) and the “embrace and extend” mentality of Microsoft, which intentionally introduces minor incompatibilities which are in their interest to do, as long as they have the major market share.

All the frameworks seem to share in common Reset CSS as a starting point – the idea being to reset all the different browsers’ handling of default styles to a minimal baseline, and then build something consistent on top of that.

Seems pretty clean, although debugging in Firebug is slightly more difficult, as all the basic styles list all the tags, so you have to scroll through all the noise to find your actual changes  / styles.

Most or all the candidates add a “grid” of standardized column widths and typography heights to the minimalist reset CSS, and strive (mostly successfully) to greatly simplify the HTML/CSS development cycle by providing some easily followed guidelines for standard practices such as columns, headers, margins separation, font sizes, and so forth – taking the “CSS Box Model” well beyond the do-it-yourself mess of quirks that it is now.

They also all attempt to hide or eliminate (or have already dealt with) the many cross-browser quirks and issues, making your design instantly supported on most or all of the available browsers out there.

When followed, they minimize or eliminate the “Butterfly problem” – where small changes can have vast consequences – the storied example being, a butterfly flying on one side of the earth can cause vast disruption and unrest at the antipodean point 12,000 miles away :).  In other words, it eliminates the frustration and irritation of changing one little thing in CSS, and having it break your page layout completely – or even worse, it appears to fixit on the browser you’re using, but displays completely wrong on IE or some other browser-du-jour.

The Background

From Wikipedia, here is an excellent and comprehensive List of CSS frameworks.

The Players

The ones we looked at, are:

  • Blueprint CSS – This is the most established and well-known, with enough of a following that there are many third-party howto’s and plugins available, as well as integration with other frameworks, sprites, and so forth.
  • Boilerplate – This one is more minimalist, with more semantically meaningful class names than “span-4”, etc – although surprisingly, even though it claims to be more minimalist, it offers no compressed or one-file version to minimize downlaods, thus making the download footprint larger. Althgough it looked promising, it’;s also over a year old, and doesn’t show any recent activity.  “Needs documentation” is one of the 4 or 5 issues in Google Code.
  • 960 Grid System – This is one of the newer frameworks, and has gotten good reviews and critical acclaim, and uses a slightly different grid scheme with wider column spacing (10px on both the left and the right) and easier divisibility by more & different numbers (the number 960 has a lot of factors).  It also has nicer typography and a well-thought-out font list for graceful degradation on Linux OSes and with other browsers.
  • Bluetrip – This combines the Blueprint base framework with the more typography-oriented Tripoli framework – an takes the typography elemn
  • Elements – A project-wide framework and directory structure, for more than CSS. Includes a CSS lightbox.
  • Typogridphy – A Typographical and Grid Layout CSS Framework From Harry Roberts of CSS Wizardry
  • Fluid 960 Grid System – This is a really impressive one – and would be great for a fluid site, with colum and spacer/site margin widths based on percentages, that works – and without using tables. We’ll be taking a closer look at this one on the next fluid site we do.

The First try

So, since we liked the Linux and typography support of 960gs, along with its elegant simplicity, we started with 960gs.

A while after we got it set up, got the pages displaying, and we noticed:

  • It had three files, and although there were compressed versions in the standard distribution tree, still this would require three connections from the server at load time.
  • Despite having the CSS images for the grid in the distribution, there was no obvious way to highlight the grid with a class.
  • eRacks had a 160-pixel left column, and a 132-pixel right column – which did not fit neatly into either the 12-column nor the 16-column grid.
  • There were some nifty plugins, addons, and jQuery integration for Blueprint – and a huge community following.  So….

The Decision

We decided to give Blueprint a try – we also noticed that nonstandard grid sizes and columns were supported by multiple tools and generators – so we surfed over to the Blueprint Grid CSS Generator and generated our 28-column grid, which nicely accomodated the left and right columns, at almost their original widths, with a 970px total width.

We also kept the 960.gs Linux-friendly font list, for smooth and nice typography on all platforms – it was a one-line override in our list of site-specific CSS, which is so small (about 20 lines) we keep it in the header of the page itself.

The Result

So we have a great-looking, prototype site up and running, and we are working on the rest of the port to Django:

eracks.librehost.com

Please note that THIS IS A WORK IN PROGRESS, and may not be available, or may not look right, at the particular time you view it!

The plugins

Useful plugins that we are also considering, are here:

  • Tabs – integrates jQuery with the Blueprint classes, to do some nicely polished-looking Tabs
  • Liquid Blueprint – Makes the Blueprint Grid liquid (fluid)
  • SilkSprite – Integrates the Silk Icons set as sprites

The Feedback

Oh, and one more thing –

We welcome and encourage your feedback and opinions on either the new eracks site, or on the above review of CSS Frameworks and our decision.

j

Django Admin and TinyMCE HowTo

Monday, December 22nd, 2008

We’ve just rolled out TinyMCE to use with our Django Admin interface.

As we encountered several gotchas along the way, we felt it would be instructive to the community to illustrate the steps here, in true cookbook (aka “HowTo”) fashion.

Here we go…

The Cookbook

Step 1: Add your js to your Model’s Admin definition:

class MyBoffoModelAdmin (admin.ModelAdmin):
    fieldsets  = (
        ... yada yada yada...
        (None, {'classes': ['edit'], 'fields': ('content',)}),
    )
    class Media:
        js = ['/tiny_mce/tiny_mce.js', '/js/textareas.js']

Note:

  • The classes : [‘edit’] which tells the code below to set the class for the mcEditor
  • That after the standard include of tiny_mce.js, the second javascript reference in the js list, is your custom init code that you will be writing next.
  • The nested “Class Media” tells the Django Admin interface to include the references to these .js files in the header of the Admin page.

Step 2: Write your initializer Javascript code:

This is the contents of /js/textarea.js:

function mce_setup()
{ tinymce.DOM.addClass (tinymce.DOM.select('.edit .vLargeTextField'), 'mcEdit');

  tinyMCE.init({
    mode : "textareas",
    theme : "advanced",
    editor_selector : "mcEdit",  // doesn't support selectors, only classes, despite the name
    height: "480",
    width: "90%",
    element_format : "html",
    plugins : "preview,fullscreen",
    theme_advanced_buttons3_add : "preview,fullscreen",
    theme_advanced_toolbar_location : "top",
    theme_advanced_toolbar_align : "left",
    theme_advanced_statusbar_location : "bottom",
    //theme_advanced_resizing : true,
  });
};

Notes:

  • This Javascript is executed in the header – and it does NOT initialize the editor yet, it merely defines a function to do so, which is called when the user clicks on a link, which we’ll see next.
  • The “addClass” call at the top is necessary to work properly with Django – despite the ‘editor_selector’ setting in the tinyMCE.init paraeters, this does NOT accept a css selector, only a class – so we have to manually set up a new, unique class, using the tinymce.DOM.select call at the top.
  • The selector of  “.edit .vLargeTextField” pinpoints the actual textarea under the fieldset with the “edit” css class.

Step 3: Add your HTML to the model:

We turn it on using the Django Model Fields’ help_text option, thusly:

content = models.TextField (blank=True, help_text='''HTML Content -
    <a href="javascript:mce_setup();">Click Here</a> to edit - see
    <a href="http://wiki.moxiecode.com/index.php/TinyMCE:Configuration">TinyMCE Configuration</a>
    for more options.''')

That’s it!

When you restart and load the page, you should see

“HTML Content – Click Here to edit – see TinyMCE Configuration for more options.”

at the bottom of the textarea in question that you set the ‘edit’ css class on –  and note that the other javascript isn’t loaded until you actually click on it, speeding load time of the page.

Clicking should quickly load the TinyMCE editor and buttons, resize the text area appropriately, render any HTML with WYSIWIG, and follow page resizes.

The Gotchas

  1. Django doesn’t let you get at the actual textarea class, so you have to do the above selector
  2. TinyMCE’s editor_selector parameter doesn’t use, or work with, selectors (!)
  3. You could use the Django form id, but then this whle precedure wouldn’t be generic, you’d need one init js per field.
  4. You would also need to set up the tinyMCE.init parameters to use ids rather than classes, too.
  5. Setting  “theme_advanced_resizing : true” actually takes away functionality if you have setup up height and width as percentages – which accomplish the same thing with no extra js.
  6. If you’re getting gibberish like “<br mce_bogus />” added to your empty text areas, there are a few things you can do – write us for details – you may need to set up an
    editor_deselector : "mcNoEdit"
  7. and use the appropriate code to add the class at the top of the setup function:
    tinymce.DOM.addClass (tinymce.DOM.select('.vLargeTextField'), 'mcNoEdit');

Useful References

Django Admin Media – Using extra js & css with the Django Admin interface

TinyMCE API – Core API, DOM API including how to find elemnts by selector, and add a class

TinyMCE Examples – Examples with source code including click-to-load, dual/partial textareas, plugin activation, fullscreen, etc

Django Model Documentation – including the help_text option which allows HTML!

Honorable Mention

An Honorable Mention goes to the WYMeditor – an up-and-coming WYSIWYM editor – What You See Is What You Mean – and it’s been getting rave reviews.

It uses a class-based approach, which is intriguing and feel right – it just doesn’t have the polish and full feature set that TinyMCE does right now – but we’ll be exploring this further in a future post, as we’ve already implemented it for a client in Django Admin already :-), and it works well –

j

Review of Django Database Migration Tools

Monday, September 1st, 2008

Update 12/1/08 –

South Logo - Django MigrationsSee comments below, and look for a new blog post from us on a new player which we’ve recently discovered – south:

http://south.aeracode.org/

They even have their own review of the other players, here:

http://south.aeracode.org/wiki/Alternatives

We will post a review on this soon.

Preamble

Following is a review I did recently for one of our Django clients, of six or so of the various tools available to handle database migrations – much like the “Migrations” facilities built in to Ruby on Rails.This list is by no means complete; as there are a lot of players our there – too many – so many, in fact, that no clear winner has emerged.  Read on.

The Reviews

The issue is how to handle schema migration and schema version control in a way that integrates well with the usual Django development workflow.

Here is an excellent Django-centric view on the topic, with proposed solutions and some of the projects currently available:

http://code.djangoproject.com/wiki/SchemaEvolution

I have checked all the references in the article, and some further ones I have found –
here are the candidates for use, and my evaluations:

Django Evolutions

http://code.google.com/p/django-evolution/

  • Mature, active, likely candidate for future Django inclusion
  • Postgres support the strongest, MySQL weakest
  • Establishes a baseline, rather than introspects – stable, conservative approach
  • Creates two new tables for the baseline – django_project_version, django_evolution
  • Does not help for our current situation
  • Builds on RoR / ActiveRecord? ideas, takes one step further

Django Schema Evolution

http://code.google.com/p/django-schemaevolution/

  • Based on the above article/link & observations
  • actually does introspections, too
  • MySQL support the strongest
  • Would work well for us, except it faults on current Django SVN release we are using (I filed the issue on Google code for the project).

deseb – Django External Schema Evolution Branch

http://code.google.com/p/deseb/

  • Appears to be a current project, with a very active community
  • this appears to be a fork of the schema_evolution project, and is also based on the article/link above
  • it uses a different approach, doing signatures of the SQL, and
  • it does a virtual ‘diff’ on the Model vs the schema –
  • almost like a db ‘lint’ utility – I will post the output below or next post
  • can optionally generate schema migration scripts to be used in version control and managed deployment scenarios
  • at the very least, this is a very useful utility to compare existing Models/schema with the manage.py sqlevolve command (see output below)

BEGIN;
ALTER TABLE `blog_categories` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `blog_posts` MODIFY COLUMN `id` integer AUTO_INCREMENT;

ALTER TABLE `tagging_tag` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `django_redirect` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `django_session` MODIFY COLUMN `session_key` varchar(40);
ALTER TABLE `django_site` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `robots_url` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `robots_rule` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_profile` MODIFY COLUMN `user_id` integer;
— warning: the following may cause data loss
ALTER TABLE `wtp_user_profile` DROP COLUMN `is_subscribed`;
— end warning
ALTER TABLE `wtp_user_review` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `wtp_product` MODIFY COLUMN `id` integer AUTO_INCREMENT;
UPDATE `wtp_product` SET `is_new_image_url` = ‘t’ WHERE `is_new_image_url` IS NULL;
ALTER TABLE `wtp_product` MODIFY COLUMN `is_new_image_url` bool NOT NULL;
ALTER TABLE `wtp_genre` MODIFY COLUMN `id` integer AUTO_INCREMENT;
[lots of similar auto-increment mods clipped for brevity]
ALTER TABLE `wtp_editorial_review` MODIFY COLUMN `product_id` integer;
UPDATE `wtp_editorial_review` SET `is_published` = ‘f’ WHERE `is_published` IS NULL;
ALTER TABLE `wtp_editorial_review` MODIFY COLUMN `is_published` bool NOT NULL;
ALTER TABLE `wtp_featured_article` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_review_feature` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_user_review_feature_rate` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_screenshot_meta` MODIFY COLUMN `product_id` integer;
ALTER TABLE `wtp_screenshot_image` MODIFY COLUMN `id` integer AUTO_INCREMENT;
ALTER TABLE `wtp_product_video` MODIFY COLUMN `product_id` integer;
[lots of similar auto-increment mods clipped for brevity]
COMMIT;

yadsel – Yet Another Database Schema Evolution Library

(Formerly dbMigrations)

http://code.google.com/p/yadsel/

Reasonably active project, last updated April 2008, some / sparse community participation –

  • Bills itself as an “Active Record Migrations like project”
  • Full and wide db support, and Django support
  • Full schema inspection, ddl/uml support, etc
  • Overkill for what we need
  • Lots of docs, but no ‘Getting Started’ guide, as is customary, unlike (All1) the other candidates
  • Not installed and evaluated

dupdater.py — Django project evolution utility

http://www.methods.co.nz/django/dupdater.html

Basically a version management & deployment tool, to give you the very basics of the RoR ActiveRecord? functionality – versioned back-and-forth scripts.

  • Simple python utility script, no Django installation required
  • Does one thing, and does it well – no introspection, etc
  • Active, last updated Apr 08
  • Immune to the Django 1.0 migration problems
  • We should evaluate this further, it looks good

Great for:

  • Keeping track of your SQL db alterations
  • Keeping them under version control
  • Allowing them to move forward and backward
  • Managing deployment in various environments – Production, Staging, Development, Sandbox.

This is simple and elegant, we may want to use this along with deseb for ‘db lint’ and to help generate the updates.

dbmigration — Simple schema migration for Django

http://www.aswmc.com/dbmigration/

Currently at v0.4, and about a a year old – does not appear to have a lot of traction, although it’s widely quoted and linked to.

  • Also patterns itself after the back-and-forth AR-style scripts
  • Uses a ‘migrations’ directory per app (rather than per project, like AR / RoR)
  • Decries auto-update integrated migration tools like Django-evolution and Django-schemaevolution
  • Supports migrations written in SQL or Python.
  • Not installed or evaluated

Recommendations and Conclusions

  • Use deseb for its ‘DB Lint’ functionality (at the very least, on dev)
  • (Possibly de-fang its update capabilities)
  • Evaluate and likely use dupdater for deployment & SQL version management
  • Install/Leave django-migrations installed, to see how it tracks the baseline
  • Keep a close eye on django-migrations moving forward, to see if we can start using it, and how it tracks the baseline

j


UPDATE 09/02/08 10:03:37 PDT dupdater findings: ¶

  • dupdater is at version 0.6, and feels at least this rough-around-the-edges
  • After using it on sandbox for a while, I can’t recommend it at this time.

However, the workflow that this tries to mimic/achieve, ie, a directory of changes, numbered, which are applied in order, is a good one – We can just do this manually with our /sql/ subdirs.

There is even some support for auto-application of sqls in the app /sql/ subdirs, by the manage.py interface, if we ever choose to use it.

Updated Recommendations and Conclusions ¶

  • Use deseb for its ‘DB Lint’ functionality (at the very least, on dev & sandbox)
  • (Possibly de-fang its update capabilities)
  • Use a /sql/ directory of numbered .sql files for the db updates
  • Install/Leave django-migrations installed (at least on sandbox)
  • Keep a close eye on django-migrations moving forward, to evaluate when to start using it and how it tracks the baseline

j


UPDATE 09/07/08 12:14:24 PDT

FYI, as of 9/7/08, deseb works fine for us in our current environment, but has not yet been updated to Django 1.0.  You will have to remove it if you are migrating to Django 1.0+.

j

Now on Django 1.0b and Satchmo 0.8pre

Monday, August 25th, 2008

django-logo-positiveOK, after some serious work and refactoring, we are now up and running on Django 1.0b and Satchmo 0.8pre, as of today –

The new shop and Django features are quite impressive, and include many things we used to have to do ourselves.

You will see us gradually putting our Satchmo eCommerce ‘shop’ back together over the next few weeks to be back up to full functionality.

As always, you may reach us for sales and support via email.

j

Now Upgrading to Satchmo 0.7!

Sunday, July 6th, 2008

satchmo-front
Please pardon our dust (please order by email or phone!) as we reimplement portions of our eCommerce engine to use the new updated Satchmo Release, 0.7 (we are using SVN trunk).

Previously, we were on the Satchmo 0.6 release (and we implemented the TrustCommerce payment engine for the project, for that release).

We hope to have the eCommerce signup capability back up and fully functional within a short time.

In the meantime, we can accept your orders and support emails through our usual email and phone channels.

Joe

Satchmo Instance Now Available!

Sunday, May 25th, 2008

Go Satchmo!

Libre Hosters,

In addition to our usual Django vMachine instances, We now have a vMachine of Django’s Satchmo eCommerce engine available –

In keeping with our commitment to provide the latest ready-to-roll Django hosting, we now offer this  vm with Satchmo preconfigured.

This therefore includes:

Just indicate your preferred Database and any other packages you’d like installed in the “Custom Notes” field when you place your order.

Note that we run our shop on Satchmo and Django (and the Blog on WordPress).

j

Ubuntu 8.04 Hardy Now Available!

Wednesday, April 30th, 2008

hardyheron3-mediumThe latest release of Ubuntu is out, Hardy Heron 8.04 LTS, and it’s gotten Great Reviews so far –

And we now have our vMachine available and ready to go, with the usual package buildouts of our favorite platforms.

We are finalizing the installation scripts and packages, but currently available are Rails 2.02 and Django 0.97-SVN with others forthcoming – watch this space for details on finalized package lists.  (Our previous postings on Django and Rails indicate some of the usual choices)

Also, as always, we use the KVM virtualization technology, which provides a number of technological advantages over the other v12n solutions.

Our vMachine is based on the minimal footprint of the Ubuntu JeOS release, which is now Fully optimized for KVM, including VirtIO, according to Canonical/Ubuntu –  we have a mere 700MB basic footprint for the guest, with a full array of services including ssh.

With your favorite stack from us, your vMachine will still typically be under 900MB, even with xrdp  for your remote desktop XWindows access!

We can host your site / solution and provide any technical assistance and consulting help which you may need.

New: We can also host your desktop!

In addition to the usual VNC (and of course SSH offerings, including X) We offer RDP via XRDP, and we are working on a fully open-source version of the GPLed NX NoMachine technology – and we also hope to be able to offer Qumranet’s (A cool vendor) SolidICE  technology – watch for an announcement.