Entries in category “Frameworks”
32 entries in this category. See also: 
feed of entries in this category, list of all entry categories.
On Django’s longevity
“Django is about to be a teenager.”
I don’t remember exactly who said that, but it came up in a discussion of potential followup events to 2015’s “Django Birthday”, held in Lawrence, Kansas, to celebrate the tenth anniversary of Django’s initial public release. There might still be some parties to throw — maybe a Django sweet sixteen — but regardless of what the future holds, the summer of 2018 will mark thirteen years since the first public release, and Django will officially be a teenager.
Most pieces of software don’t ...
Let’s talk about WSGI
Recently Armin Ronacher (whose blog you should be reading if you do anything at all involving Python and the web) has published a couple of good articles poking at the current state of WSGI, the standard interface for Python web applications. Some of his comments dovetail nicely into concerns I’ve been trying to put into words for a while now, so I’m glad he’s posting on the subject and providing some context.
In short, I’ve come to have some rather severe misgivings about WSGI — both as currently constituted and as ...
PyCon ORM panel liveblog
I’m sitting about five rows back in the ballroom at the Hyatt, waiting for the ORM panel to begin.
Panel’s starting. Moderator Alex Gaynor introduces himself and panelists:
- Guido van Rossum (App Engine)
- Jacob Kaplan-Moss (Django)
- Massimo diPierro (web2py)
- Ian Bicking (SQLObject)
- Mike Bayer (SQLALchemy)
First question: brief history of your ORM
SQLALchemy: wanted to do a CMS, but never ended up writing it. Had idea for a modular library to talk to databases, different bits you could use or not use — connection pooling, SQL expressions, ORM — as you liked. Background ...
Database heresies
While scanning reddit, I saw an article pop up by Jeff Davis lamenting the way most people interact with databases, particularly when it comes to ORMs. Jeff seems to be pointing out (and, to an extent, conflating) two issues:
- At the moment, programming languages and SQL don’t really mesh all that well.
- Most people, in Jeff’s opinion, take the wrong approach to working with a database from their programming language of choice.
The first point is one I’m happy to concede; SQL is a fundamentally different beast from, well, pretty much any ...
On “conceptual integrity”
Mark Ramm has a nice post this morning talking about Adam Gomaa’s discussion of “conceptual integrity” in Python web frameworks; I think it’s worth a read.
The key point Mark touches on is good documentation: ensuring that people see and understand the overarching structure of the framework is, ultimately, the key to helping people understand how it can help them get their work done. In the case of Django there is an official “overview” document, but it’s really not as good as it could be; it’s basically a whirlwind tour of ...
Shared hosting is not a ghetto
In the wake of the Dreamhost blog’s post on Rails and shared hosting, there’s been a bit of a meme going around with respect to deploying frameworks like Rails (or Django, or TurboGears…), and which more or less consists of people asking why, if you’re using one of these frameworks, you’re not just ponying up for a VPS or dedicated server. After all, it’s not like the offerings these days are that much more expensive than commodity shared hosting.
There are some problems with this attitude, some of which are elegantly ...
Web frameworks and web hosts
Today John Gruber linked to a post on the official Dreamhost blog lamenting the state of web-framework deployment on consumer-level shared hosting; while the post itself is largely concerned with Ruby on Rails, the current state of deploying popular (non-PHP-based) web frameworks on hosts like Dreamhost is, well, abysmal. A search for “dreamhost” in the archives of the django-users mailing list turns up nearly five hundred results, many of them people struggling to get Django working, and I imagine that similar searches of list archives for other frameworks ...
The why and wherefore
So, let me straighten a few things out.
First off, this is my personal blog. What you see here is me speaking my own personal mind, and I neither represent nor want to represent anything larger: not Django, not Python web development, not my employer, not anything except me and whatever I feel like writing about. This is an important point to keep in mind, because I don’t have any claim to represent anything else:
- My role within Django consists almost entirely of bureaucracy. I’m not as smart or as talented as ...
Let’s talk about frameworks (again)
Over the past year or so I’ve written several articles on frameworks, mostly talking about the pros and cons of using them and specific design decisions pertaining to specific frameworks. For the most part this has been in the context of programming — specifically Python and JavaScript programming — because, well, I’m a programmer; this is what I do for a living. But every so often the general topic of frameworks for the Web, recently focused on frameworks for client-side technologies, rears its ugly head again and people have all ...
ORM Wars
Last week while I was still on blog hiatus, Adam Gomaa wrote up a pretty constructive summary of why he prefers SQLAlchemy over the default Django ORM, and documented how he made SQLAlchemy a little less painful to use by writing a set of helper functions before moving on to announcing that he’s writing his own declarative layer — borrowing somewhat from Django’s model syntax — on top of SQLAlchemy.
I went back and read a few of Adam’s other posts, and generally I like what I see; he manages to ...
Hypothetical framework choices
I subscribe to feeds of items tagged with “django” on a couple of sites, and tonight I noticed a link which posed a hypothetical situation of wanting to port a large J2EE application to either Rails or Django, and asking about making the choice between them.
I wrote up a reply, but attempts to post it there netted me “The page you were looking for was not found. Moron.” So here it is in all its glory; maybe someone will get some use out of it, maybe not.
Choose wisely
As ...
PyCon 2007: Web frameworks panel
(this was liveblogged during the panel, and the only later edits were to correct a couple of typos and add this notice — the content has not been changed)
Titus, the moderator, has welcomed everyone. No blood shed so far. Probably not taking audience questions.
Introduction of the panelists:
- Spyce: Jonathan Ellis
- CherryPy: Robert Brewer
- TurboGears: Kevin Dangoor
- twisted/Nevow: Duncan McGreggor
- Zope: Jim Fulton
- Django: Adrian Holovaty
Titus pauses: “The most interesting thing about Django is, it’s what Guido would do.”
- Pylons: Ben Bangert
- Pyjamas: James Tauber
Titus says he’ll spark discussion by targeting Zope. First question: there’s a wide ...
Python framework design
Lately I’ve found myself being baited into the same old debate over and over and over again, and I’m getting tired of making the same arguments each time. Usually it begins with someone lamenting how Django is anti-community or too inflexible or generally suffering from a raging case of NIH. From there it progresses into people proclaiming how TurboGears or (more often) Pylons is objectively “better” because of how they’re designed, and how it would be nice for Django to follow their lead.
Before I go any further, I’d like you ...
Choosing a JavaScript library
Previously we looked at some objections to JavaScript libraries and some possible responses. Now it’s time to ask a bigger question: do you need a JavaScript library, and if so how should you go about choosing one? I’m not going to recommend any particular library, because I don’t think there’s such a thing as one-size-fits-all in web development, but I can list a few things which are useful to keep in mind when making these decisions. So let’s dive in.
Do you need a library?
No matter what language you’re writing, libraries ...
Django and NIH
Just so you know, Django is a smug, arrogant framework that doesn’t play nice with others. The developers are smug, arrogant assholes who don’t care what anyone else does or what other tools are available, and who always insist on doing things their way. Django absolutely refuses to support cool “standard” Python tools and libraries unless they were implemented first for Django. Just stay the hell away from it, and teach those goddamned Django people a lesson by doing so!
Or at least, that’s the impression you’d get from reading the ...
How I got here
I’m not a formally-trained programmer. I wasn’t a computer science major in college (my degree is in philosophy), and my first job after graduation didn’t involve programming (it was phone-based customer service at a health-insurance company). But here I am, developing software for a living.
I’ve never written a compiler. I’ve never hand-tuned something by dropping in bits of assembly, or even by writing C extensions for an interpreted language. I’m too young to have ever hacked on a Lisp Machine. But here I am, developing software for a living.
My language ...
Friday fun
It’s the end of the week and, while I’ve got plenty of things I could write about, I’m sort of tired and burned out. So let’s just look at a couple things that went on this week.
Django performance with foreign keys
There’s been a bit of a to-do the last few days over a supposed performance problem in Django. I have a hard time classifying it as a “bug”, though — the whole thing centers around the fact that, to generate an HTML select box of possible choices for a foreign ...
Let’s talk about frameworks, security edition
It’s been an exciting week, hasn’t it?
The Rails vulnerability touched off quite a firestorm of commentary on the security of web application frameworks (and, by extension, applications developed with them), so let’s bring back the frameworks series for one last hurrah and take a look at security.
What do we mean by “secure”?
This may sound like a strange question to ask, but it’s an important one. A common misconception is that an application is “secure” if it doesn’t have any “bugs”. Setting aside the fact that this just switches out one ...
Helpers, scaffolding, tradeoffs and other stuff
In one of the very, very few coherent things I’ve seen him say in comments posted here and elsewhere, one Lucas Carlson brought up the other perceived advantage of JavaScript helpers: they save time:
Sure it is possible to add javascript helper functions to Django, and yes that would speed up initial development times and reduce bugs since Python is usually more terse than JS… even for expert JS programmers.
I’m going to ignore the “fewer bugs” argument because it seems to me that writing code in one language ...
JavaScript, ORM and “hiding SQL”
So my little rant on AJAX support in Django apparently touched a nerve with a couple people; that means it’s time to write more about it.
One of the common points people have been raising, in comments and elsewhere, is that I shouldn’t rail against “hiding JavaScript from the developer” when Django’s ORM already hides SQL from the developer; from the perspective of a server-side developer, SQL is just as important, right?
Yes, SQL is just as important. But having ORM isn’t “hiding SQL”.
What ORM is
The intialism “ ...
How Django processes a request
In a comment he left yesterday, Jonathan Snook posed an excellent challenge: document the chain of how Django processes a request, from start to finish, with plenty of detail on the various things being called internally and links to the appropriate documentation.
Simon Willison once wrote such a document, but it was a fairly high-level view and a fair number of things have changed since then, so I’m going to take a stab at it myself, and hopefully the result will be comprehensible.
Note: this is a first draft. Not a finished ...
Let’s talk about frameworks: When frameworks aren’t right
I know, I know, I said I was done with the series. But there’s one more thing I’ve been feeling like I should have mentioned: when frameworks aren’t the right choice for a project.
The big belly, revisited
Remember that image? It shows the types of projects for which I think frameworks are a good choice, the 80% or so of web projects which can all be handled by a database-driven application and gradual scaling of the hardware. Which, logically, indicates that other types of projects — basically, those which aren’t ...
Django tips: Write better template tags
Django‘s template tags are a great way to handle things that don’t always make sense being in a view. If you want to have, say, a list of recently-added content which appears in a sidebar or footer on every page of a site, it’d be crazy to manually change every view to fetch that content and add it to the template context; a template tag is definitely the way to go.
For example, in the footer of every page on this site, I pull out the five most recent entries ...
Django tips: extending the User model
One of Django‘s great strengths is its built-in user and authentication system; the bundled application django.contrib.auth includes models for users, user groups and permissions and views for logging users in and out and changing and resetting their passwords. This is enough to cover the needs of a huge number of sites and, after the admin, the auth system is probably the most popular bundled application Django ships (or maybe the other way around, since the admin requires the auth system to be installed).
Because of the auth system’s ...
Templating languages redux
So, I thought I’d explained why templating languages are pretty useful things. Markup is, after all, just about the fastest and simplest way to, well, mark up content for presentation and, when coupled with a small amount of logic, is by far the best way to present the output of a dynamic database-driven web application. I kind of hoped that I wouldn’t have to write more on the topic, because there are so many more interesting things to which I can devote my time.
Sadly, I was mistaken. Enter one Colin ...
Let’s talk about frameworks, DBA edition
In the previous entry in this series I took a look at some common criticisms programmers level against the new generation of web-development frameworks. Today I’ll be following up in somewhat the same vein, by expounding on something that might lead your friendly local database administrator to look somewhat askance at how these frameworks do things.
And let me say right now, before I ruffle anyone’s feathers, that when I talk about applications and databases below, I won’t be talking about any particular application or database. I’m not engaging in thinly-veiled ...
Let’s talk about frameworks, programmer edition
In the previous entries in this series I’ve been talking mostly about the benefits of the new web frameworks that have been popping up over the last year or so. And from a programmer’s perspective, there are certainly a number of benefits:
- Speed. Because a framework gives you a solid foundation of code for common functions, it also gives you a pretty big head start on a new project. Generic data modeling and object-relational mapping, coupled with solid data-access APIs give you an even stronger boost, cutting development time significantly.
- Flexibility ...
Let’s talk about frameworks, designer edition
Yesterday we got a brief overview of the new generation of web development frameworks and a general idea of why people are so excited about them; today let’s dive in and see what frameworks can do for the designers in the audience.
You don’t have to do (much) programming
This is probably the biggest factor I’ve seen drawing design-oriented people to frameworks. There are plenty of people out there who’ve mastered HTML and CSS, but couldn’t program their way out of a paper bag. And a significant number of designers also ...
Let’s talk about frameworks
So you’ve been hearing all this hype about “frameworks”. People from all over the world of web design and development are raving about the way their lives have been changed by things with mysterious names like “Rails” and “Django”, and you’re scratching your head, wondering what all the fuss is about — is this just a fad that’ll pass, or is this a geniunely important new development? Maybe you’re wondering just what, exactly, these “framework” things are, and what they can do for you.
Some of the answers to these questions ...
Why templating languages aren’t a bad idea
Before I get into any meaty details, a quick question. You have a dynamic, database-driven web application and you’re ready to sit down and bang out its HTML output. One part of one page will be an ordered list containing comments left by visitors. You have the following choices for doing this:
Option A:
<ol class="comments"> {% get_comment_list %} {% for comment in comment_list %} <li>{{ comment }}</li> {% endfor %} </ol>
Option B:
item = page.new_content_element('ol') item.class = 'comments' for comment in db.get_post(post_id)['comments']: c = item.new_subelement('li') c.contents ...
Django, gzip and WSGI
One of the many things I like about Django is the range of available middleware you can use to do all sorts of interesting stuff. But one in particular has got me a little bit stumped.
One of the available middleware components for Django allows content to be gzipped for output when the client specifies ‘gzip’ in its Accept-Encoding header; this is handy because it both conserves bandwidth and allows pages to be downloaded more quickly. Most popular web servers allow this (Apache via mod_deflate, lighttpd via mod_compress, etc.), but it’s ...
The Google Web Toolkit
So Google went and released something that people are calling an “AJAX toolkit” and, as so often happens whenever Google does something, the Internets are buzzing. But, in the long run, I don’t think this is going to be a game-changing move, and I think that should be pretty obvious to anyone who sits down and thinks about it.
The first question to ask about Google Web Toolkit is simple: who is it useful for? Obviously it’s useful for Google, but it looks an awful lot like it’s only really ...