Jul. 13th, 2010

elfs: (Default)

As I’ve been working on a project at Indieflix, I’ve been evaluating other people’s code, including drop-ins, and for the past couple of days a pattern has emerged that, at first, bugged the hell out of me. Django has these lovely things called context processors– they allow you to attach specific elements of code to the request context before the router and page managers are invoked; the idea is that there are global needs you can attach to the context in which your request will ultimately be processed, and this context can be grown, organically, from prior contexts.

Nifty.  I kept noticing, however, an odd trend: programmers attaching potentially large querysets to the context.  Take, for example, the bookmarks app: it has a context processor that connects a user’s bookmarks to the context, so when time comes to process the request if the programmer wants the list of the user’s bookmarks, there it is.

It took me three days to realize that this is not wasteful.  It says so right there in the goddamn manual: QuerySets are lazy — the act of creating a QuerySet doesn’t involve any database activity. So building up the queryset doesn’t trigger a query until you actually need the first item of the queryset.  It just sits there, a placeholder for the request, until you invoke it in, say, a template.  Which means that you can attach all manner of readers to your contexts, and they won’t do a database hit or other I/O until you drop a for loop into a template somewhere. I’ve been avoiding this technique for no good reason.

This also means that pure “display this list and provide links to controlling pages, but provide no controls of your own” pages are pure templates that can be wrapped in generic views.

Ah!  And this is why I didn’t get why generic views were such a big deal.  Information is often so context sensitive so how could a generic view possibly be useful?  The examples in the book are all tied to modifying the local context in urls.py, but that’s not really where the action is.  The action is in the context processors, which are building that context.

I feel like Yoda’s about to walk in and say, “Good, but much to learn you still have, padawan.”

This entry was automatically cross-posted from Elf's technical journal, ElfSternberg.com
elfs: (Default)
There's a meme going around to analyze your writing in the belief that somehow you write "like" someone else. I'm suspecting some trivial keyword magic: the word "robot" automagically gets you Asimov, for example.

Many and varied. )

Dan Brown? Really? That's sad. I'll buy Palahniuk for Fortune Cookie, but I suspect it was "gasp" and "rope" that did it there.
elfs: (Default)
Museum Quality or Market Success.

This is one of those articles that depresses me. I love The Dieline, and all the brilliant student work, but the message of this article is to not exceed any given cliche' by too much, or you'll be doomed.

You see, everything I've learned about social network design is going into the Sekrit Project, and one of the things I wanted to do is make smut safe to consume-- to make the table of contents and so forth look less like porn and more like something you'd feel comfortable reading on a bus. With the advent of pads and tablets and smartphones and so forth, the last remaining "right" tasks of erotica distribution are public acceptibility and monetization.

But this article makes it sound as if, if you hit that note where people over your shoulder need to actually read in order to be shocked-- a scan is not enough-- you won't find your audience, because they're still expecting garish red backgrounds, out-of-date static layouts, and cheesy ornaments. And a layout that looks more like the NY Times and less like the back cover of Penthouse won't sell.
elfs: (Default)
This evening I headed over to the Seattle Django Get-together. I haven't gone in a few months, and the topic of tonight's talk intrigued me: "Tree UI with django-treebeard." I've had to do recursion and tree structures a lot, mostly at Isilon but also with the Sekrit Project, but I've done it mostly on the code side using tag includes. I wanted to see what this guy's solution was, since I've thought about doing it using templates but never actually implemented it.

He discussed the problem, and then said, "I put in all kinds of keywords into google looking for it, and I found this one great article called 'Template recursion in Django with Treebeard.'" And he put up a very familiar slide. He said, "It's by this guy named Elf Sternberg."

"That would be me," I said.

"Really?" He was very good about it, not awkward at all. He showed the demo, including some awesome jQuery-based solutions for managing parent/child selection issues before committing them to the server.

I also showed him the paleo code and we discussed ways of abstracting and refining the problem.

I got the impression from the post-presentation conversation that jQuery is de-facto standard for Django, to the point that Django hackers are expected to know it.

That was kinda cool, actually. Now I want to go and refine the article (show how to do it as a template tag, rather than a view) and finish the DWIM HTML in Python series.
elfs: (Default)
Any movie with both Jeff Bridges and Jonathan Price would have contained as much awesome as a Christopher Walken marathon.

Profile

elfs: (Default)
Elf Sternberg

June 2025

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 29th, 2025 10:22 pm
Powered by Dreamwidth Studios