May 17, 2012

Posts Comments

You are here: Home / Languages / Python / Django

Howto use Satchmo as an App

January 10, 2007 By Bruce Kroeze 3 Comments

Note: This article is out of date. Since I wrote it, I’ve become a core developer on the Satchmo project, and Satchmo is usable by default as an App (or rather a collection of apps) rather than as the whole project.

I’m going to be using Satchmo to power the backend of a highly customized store that I’m building for a new client. This is an early-stage, yet strong Python ecommerce framework, which gets much of its power by being built on Django.

Of course, anyone reading my site can clearly see that I am strong in favor of that choice.

I ran into one little issue when I was first setting it up according to the directions. I was told to modify files in the Satchmo directory itself. No! I won’t do it! Not on an actively developed application like that. How would I keep my modified branch in sync with the development branch?

Why is that wrong?

In general, you never want to modify something that is a moving target. Even if it is a hassle, you should set things up so that the thing-which-will-be-getting-updated is isolated from your own code. Otherwise you’ll certainly have to face that most annoying of development tasks, merging someone else’s code.

Well, luckily it wasn’t so hard to set up Satchmo for use as an App, rather than as the base site.
[Read more...]

Filed Under: Best Practices, Django, Open Source, Python

Django Newforms HiddenInput Values

January 3, 2007 By Bruce Kroeze 4 Comments

I really like Django’s newest module for forms, “newforms”. Despite its currently lacking documentation, it is well worth learning.

It feels much more “Pythonic” than the old manipulator-based method. Less magic is going on, and less constant reference to the manual is needed. However, I found myself beating my head against one undocumented, and also lacking any test case feature.

How to get newforms “hidden” fields to have a value

I’ll spare you the trials, tribulations and shrewd guessing, here’s the answer. Put the value in the widget attributes, not the form field.

[Read more...]

Filed Under: Django, Python

Django Formatter Mixin Class

December 27, 2006 By Bruce Kroeze Leave a Comment

guitar Django Formatter Mixin ClassI’ve always disliked having to write __repr__ methods for my classes. It isn’t hard, it is just tedious. In Django, it is especially important to make them, since the admin pages use that method when listing objects from the data model.

However, since Python allows classes to have multiple inheritance, I have long since made a helper “Mixin” class to remove most of the pain from writing my __repr__ methods. If you haven’t heard the term, a “Mixin” is a class which adds functionality to classes which inherit from it. The philosophy is that it shouldn’t change base functionality, thus avoiding many of the problems with multiple inheritance.

Philosophy aside, mixins can be extremely useful, and I love this one. [Read more...]

Filed Under: Django, Open Source, Python, Tips

Stats on a larger Django project

September 29, 2006 By Bruce Kroeze Leave a Comment

diamond1 Stats on a larger Django projectA Django website that took (a lot) more than 20 minutes. Interesting writeup of a meta-forum app, including code samples and time breakdown.

Found via Django Forums.

[tags]django[/tags]

Filed Under: Django, Python

Zyons Forum for Django

September 16, 2006 By Bruce Kroeze

handshake 2 Zyons Forum for DjangoThis summer, I’ve been converting my biggest site, Invisible Castle, from Cheetah to straight Django. At the moment, Invisible Castle is run on straight CGI, using Cheetah to render the pages, so this is a rather big conversion.

I’m not just changing the template, that part is surprisingly simple, but the whole page flow logic. From stateless to a full web app. It is interesting, going quickly and the site will be much stronger when I’m done. It already gets 20-50K hits a month, and with my changes it will be able to take a lot more hits and handle them more quickly.

What’s the point?

Ah, but what’s the point? Why bother? Well, partially I just wanted to see how easy it would be, and because I find Cheetah templates annoying to maintain. But more importantly, after conversion, I’ll be able to use Zyons forums, and integrate them into the site. Zyons is a nice, full featured forum app, written using Django. So, I’ll be able to integrate my current app into a forum. How great is that?

Just try that with some hacky PHP forum. I dare you. I am absolutely certain it will work, and work smoothly. I can hardly wait to integrate and bring this dream to life.

[tags]django,cheetah,forum,zyons[/tags]

Filed Under: Django, Python

A Django Killer App – Web Table Data

September 12, 2006 By Bruce Kroeze 2 Comments

light bulb yellow A Django Killer App Web Table DataYet another great use for Django is to make trivial the creation of shared tables & forms for internal projects. It is one of the most common needs in any size company, “Make me a web form to capture these data.” “Oh, and make sure to keep it locked down so that xxx dept can’t see it, and only you and I can modify it.”

Making these kind of web apps is one of the most boring tasks possible, yet they are both common and almost always poorly implemented. After all, they are just for internal use, right? And “they” rarely give you enough time to make a decent app anyway.

Well Django to the rescue. In four steps, you can have an app with far more functionality and usability than you’d ever have with some quick-hack up PHP page or ASP.

Step 1: Create the project directory and app directory

$ django_admin startproject projectbase
$ cd projectbase
$ ./manage.py startapp projectname

Step 2: Edit projectbase/settings.py
You can leave most everything default, at the simplest you can simply use a SQLite database, which requires no password or database setup. Be sure to enable the admin app, like so:


DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = '/path/to/your/project.db'
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''

INSTALLED_APPS = (
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'projectbase.projectname'
)

Step 3: edit projectbase/projectname. Models.py: Here you put the class or classes you want to track in your table. Here is an example taken from a simple migration tracking app I made at work.


from django.db import models

class Migration(models.Model):
    account = models.CharField(maxlength=30)
    email = models.EmailField(blank=True, null=True)
    prop = models.CharField(maxlength=30, null=True)
    requestor = models.EmailField()
    domains = models.TextField()
    target = models.CharField(maxlength=6)
    status = models.CharField(maxlength=20,
                              blank=True, null=True)
    created = models.DateField(null=True, blank=True)
    scheduled = models.DateField(null=True, blank=True)
    completed = models.DateField(null=True, blank=True)
    archived = models.DateField(null=True, blank=True)
    notes = models.TextField(null=True, blank=True)

    def __repr__(self):
        return self.account

    __str__ = __repr__

    class Meta:
        get_latest_by = "created"
        ordering = ("created",)

    class Admin:
        list_display = ("account", "email", "prop",
                        "requestor", "domains",
                        "target", "status", "notes",
                        "created", "scheduled",
                        "completed", "archived")
        search_fields = ("account", "domains")

Step 4: Create the database and tables

$ manage.py syncdb

At this point, you have a full fledged system available to you. Start Django however you please, add a few users and show off. You’ll have a full app available, with sorting of tables, updating, searching, and full authentication. All in a half hour of work.

[tags]django,killer app,python[/tags]

Filed Under: Django, OS, Tips

Speedy Django Development

July 7, 2006 By Bruce Kroeze 3 Comments

guitar Speedy Django DevelopmentAs I’ve mentioned before, I am building my own web store using Django. The coding is going extremely quickly, thanks to the excellence of the framework.

I find myself marvelling at how quickly and simply various elements come together, especially when I contrast this to my previous experience doing the same thing with Java for an employer.

For example, the Login/User framework. With Django, I simply include the auth middleware, and create a couple templates to “skin” the login, profile, password change, and password reset pages. In return, I get a full-featured, working login system with sessions, cookies, and all that tedious plumbing done for me. Total time from decision to use the built-in framework to implementation? Two hours, including learning the system. Unbelievable.

Contrast that with my use of Acegi/Spring to handle authentication in a Java app. I was shockingly fast implementing this, taking just two full working days. The documentation directly states that you should plan on at the very least one full week. The system was huge, slow, and baroque. Modifying the system was clumsy and frequently required I relearn things from the reams of documentation. Yes, overall it offered more functionality. No, there was no stripped-path to just get the most needed set of features for a website. The craziest thing is that the config files for Acegi
alone were larger than all the code and templates I wrote for django login.

Another example is my need to generate thumbnails for some graphics. I want to generate them “on the fly”, when needed. Total lines of code to do this in Python with PIL, integrated with Django? 7. Total time? 15 minutes, including all the logic needed to make sure that I only create the thumbnail once.

Contrast this with the nightmare that is the Java image API. I seriously spent days making a caching thumbnailing system in Java for an Auction site I worked on. Even after that, it was much slower than my Python solution.

Now that I am actually developing a serious app for Django, I find myself feeling the love more and more. Thanks Django team!
[tags]django,python,spring,acegi,pil[/tags]

Filed Under: Django, Java, Languages, Python

Magic Removal Success!

May 1, 2006 By Bruce Kroeze Leave a Comment

classical guitar Magic Removal Success!I’m pleased to report that the Django magic removal branch is now much easier to use. It feels stable, the docs are getting complete, and I see now that the branch has now been officially merged to the head.

My magic-removed code works great, and is passing all its tests with flying colors. Total time taken for 3 apps was approximately 4 hours. The only real pain was in updating the database. I feel certain I could have made it work, but I took a shortcut and simply reset the whole thing.

manage.py syncdb is sweet!

[tags]Django,magic-removal,python[/tags]

Filed Under: Django, Libraries, Python

Django Magic Removal, this time for real

April 27, 2006 By Bruce Kroeze Leave a Comment

guitar Django Magic Removal, this time for realDespite my earlier initial successes using the Django Magic-Removal Branch, I had to roll back. The branch code was stuck in an unusable state for a couple weeks when I was really wanting to crank out some functionality on my storefront.

I’ve long since learned that when you have a strong urge to code, you should do it right then, not put it off for when it would be more “convenient”. It won’t be, and you’ll lose precious hours of probable “flow programming.” So, I rolled back and worked off the .91 codebase.

This time there’s no looking back

Because the branch is supposed to merge to the head of the tree today, I have no choice remaining. Ah well. I spent three hours last night merging my three Django apps. I’m not quite done, but all that’s left is the database API changes, and my DB calls are all well isolated.

Not only will I be “on the mainline” of the Django code, but when the code is all merged I’ll be able to use the far more intuitive new API. I’m honestly quite happy to see them break with their old API before they release the 1.0 version. That way they don’t have to support cruft, which slows down development. Possibly more importantly, they obviously have applied “lessons learned” when refactoring.

This isn’t some little change. It is “shoring up the foundation” before major new functionality is built on it. I can’t wait to see what happens next.

Up next, more ECommerce

For my part, I’m getting more involved with the Django yet-to-be-named ecommerce shopping module. It is amazing what just a few Django programmers can throw together in a few days, really a testament to the productivity of the framework.

[tags]django,magic-removal,python[/tags]

Filed Under: Django, Python

Django on Rimuhosting

April 13, 2006 By Bruce Kroeze Leave a Comment

thumbs up Django on RimuhostingThis is just a quick post to confirm that Django does indeed work perfectly on Rimuhosting with very little effort required to set up. It is fast, it connected to my Mysql db without a peep of a complaint, and it is making me a happy developer.

Setup details

I’m using Rimu’s “MiroVPS3″ plan. It is $39 a month, less 10% for being an open-source developer. It provides 4G hard drive space, 60G bandwidth (in and out combined), and 160 MB ram.

I’m running the following “stack”:

  • Debian: I know and love Debian much more than any other Linux distro. Almost everything is installable with a simple “aptitude install whatever” command.
  • APF: firewall, set up according (mostly) to the instructions on Webhostgear. I had to tweak it for Debian, by setting “monokern=1″ and by symlinking /etc/rc.d/init.d to /etc/init.d
  • Imap/Smtp set up according to the instructions on The Perfect Rails/Debian/LightHttpd Stack article.
  • Mysql: Actually not my favorite db, but I didn’t want to convert to PostgreSQL at the moment, at least not until I’d proven my existing dev setup worked. Rimu set this up for me, since I’d requested a Django setup.
  • PIL: I need the Python imaging library, so “aptitude install python-imaging” did the trick.
  • python_mysqldb: Another simple “aptitude install python-mysqldb”
  • Apache2 with Mod_Python: Apache2 is more flexible about vhosts, and I’m going to use the heck out of them. Mod_python is the preferred deployment environment. I am not using any other mod_plugins. Rimu set this up, and I made vhosts entries based on what I read in the django documentation. The only “tricky” bit was setting up a different vhost for the media URLs. I did that one without mod_python support, to make for lighter server threads.

It is a very responsive environment. I can hardly wait to deploy some real apps on it very soon.

[tags]django,rimuhosting,debian,vps setup,python webhosting[/tags]

Filed Under: Django, Hosting, Python, Tips, Uncategorized
« Older Posts
Newer Posts »