Unbracketed

Django Komodo Kit Project

Based on some mutual interest I am launching the Django Komodo Kit project.

Queryset-Refactor Lands in Trunk

Malcolm Tredinnick (whom Adrian Holovaty described in his PyCon 2008 presentation as "this Australian guy who is like a Django god") has just finished merging the queryset-refactor branch into trunk. The wiki page summarizes the changes in detail so go ahead and take a gander there to get a glimpse of what to expect. Collectively this branch brings a number of features that will make it more intuitive to get the results you want with less code. Model inheritance (covered earlier here) will also be a big win.

One nice side effect of the merge is that once the newforms-admin branch merges with trunk to incorporate these changes, developers won't have to choose between the two branches anymore. If you are preparing your applications for the goodness that Django will soon bring you now only need to code against the newforms-admin branch.

It is hardly enough to just give kudos to Malcolm for his work. Well, to be sure many others put in effort in terms of ideas, advice, reviewing, and testing code. However Malcolm did the heavy lifting and the desire to produce a first-class product shines through. This may be a little unfair to take his words out of context, but on his blog about a month ago he mentioned:

I've been doing all this reading in an attempt to get out of a bit of a funk about writing code and designing things. It's not too serious, but I'm grumpy a lot and missing the feeling of being enthusiastic about stuff and have been spending a lot of time trying to work out why this is the case...

...I want to work on something that matters, something that has a completion point and will be useful. Contributing to projects like Django are still fun, obviously, but that's mostly doing little things to help out others and sometimes I'm not as invested in it as I should be. I think I'm missing the fun of working on something that is hard but realistic and which can be said at some point to be done. I'm also worried that the lack of periodic work with teams is not giving me any outlet for ideas or source of problems. I'm hardly a hermit, but I sometimes miss working closely with other people and succeeding together on something that is non-trivial. Self-education is fun and something I do a lot, but the real world tends to throw up a lot of interesting problems that you don't see in the books.

Defying Classification: Software Development Motivation

I think Malcolm is being modest and/or underestimating his own abilities here. I've never written an ORM but I've used a handful across a few languages and I've put just enough thought into their construction to realize that they are complex beasts to get right. When one accounts for the fact that Malcolm also regularly participates in the Django user group as well as fixing bugs it becomes clear that this is one talented guy. I believe that Malcolm is truly a shining star in open source development and we in the Django community are very fortunate to be able to utilize his efforts.

Malcolm recently interviewed by the 42topics blog and also made an appearance on the "This Week in Django" podcast. If you are fortunate enough to encounter him in a social setting please do pay for his meal, buy him a beverage, and pass along an enthusiastic thanks for me.

A Delicious Perspective on Popular Django Projects

After hearing from Bryan over at Django Plugables that tagging on the list of projects would not be open to outside input, he was open to the idea of pulling data from Delicious as a starting point. I came across an entry on Niall Kennedy's blog pointing to a JSON URL feed being available and it seemed like that would do the trick. Please note that this API is probably not intended to be used for general data harvesting. I did throttle my requests way back to be respectful. Make sure you read and understand the terms and conditions surrounding this API before using it.

Following my own curiosities, I created a list of the 25 most popular projects from Django Plugables based on total posts in Delicious to URLs associated with those projects. Below you will also find a tag cloud that shows all Delicious tags associated with all of the Django Plugables projects. Hovering over a tag will list the associated projects with links to their respective project page at Django Plugables.

Let's take a quick moment to acknowledge that this sampling is not intended to be a well-thought out or authoritative statement on the actual use/popularity of projects that exist within the Django community. It is merely the outcome of an exercise - produced by combining data from two isolated resources. If one were to order the projects listed at Django Plugables (as of April 20, 2008), the 25 most popular bookmarked at Delicious are:

Top 25 Projects (With Total Delicious Posts for Associated URLs)

Nothing surprising there. We can generalize the list to say that each of those projects meets some set of the following criteria:

Has been in existence for a while
Was authored by someone who has been with the community for a while
Provides functionality or features common to most web applications
Well written, portable Django code
Follows in the footsteps of Django's roots as a publishing platform
Just frickin' cool

Here is the set of tags associated with all projects listed at Django Plugables (as of April 20, 2008):

Find Apps to Wire Up Your Django Site at Django Plugables

One of the major underlying design principles of the Django framework is that sites should be composed of numerous modules - each with a specific purpose. This is the same ethos that has fueled both the reputation and growth of UNIX-based operating systems. With the recent explosion and certain continual growth of Django, a wonderful natural side effect will be a proliferation of great components providing features common to web applications. The task then becomes searching for and filtering the results to find exactly what you are looking for. Django Plugables has stepped up to ease this process significantly.

Conceived by Revyver, the site has a clean, spiffy design. Yet another successful example of self-proclaimed designers learning Django and being productive with it in a jiffy. This already helpful site should morph into a very useful utility once their proposed features surface.

Current Features

The main pieces of functionality the site currently offers are:

A list of hand-selected projects with brief descriptions.
A list of developers and their collective projects.
A handy page (dubbed EzayRepo) for doing quick repository lookups for your favorite projects.
Feeds for recent commits (across all projects) and recently added projects.

Searching the Projects page is the main way to filter projects at the moment but this should improve tremendously with the addition of tagging. The developer listing is a nice way to give credit to generous community members who are making their work available. They've made clear that they are not focused on creating a social-network so only the most details about project authors are listed. This should help ensure that the site's usefulness as a utility can remain a priority for the site.

Coming Soon

Voting, comments, and per-project feeds will join project tagging as new features in future iterations. It is not clear to me whether users will be able to add tags to existing projects. I am personally hoping they will make a basic REST API available because the data on this site will dovetail nicely into a community resource organization tool I am creating. I think others might find the data useful as well - I can imagine in areas such as build systems and administration.

I am looking forward to utilizing this site as a time saver in the future. More importantly, the site should go a long way toward gaining exposure for well-written, useful projects which will in turn do its part toward accelerating the adoption of Django. Very nice job Bryan and Jen!

Integrate markItUp! Into the Django Admin

What is markItUp?

markItUp! is attempting to be a universal markup editor that will support working with a variety of markup syntaxes. It is simple to setup and can turn any textarea into a full-fledged editor with just a few lines of code. They've also provided a lot of hooks to make it customizable so you can easily add new features or change the behavior. The documentation still needs a fair bit of work, but I was able to get it up and running by just poking around.

My motivation for investigating markItUp was that I realized a need to create some editing tools that would reduce the time it takes me to write posts and automate some of the styling that I like to use to highlight important keywords, people, and sites that I mention in my articles. But aren't markup syntaxes supposed to do this already? Yes they do, but it can still be tedious to manually add lot of links and add specific styling. Let me point out that my mindset with the creation of this blog has been to benefit from the learning experience. While I could of course use this, that, and the other tool/editor out there for building and managing my content, part of the enjoyment for me has been learning about the problem sets accompany publishing and content creation.

I think it is a common pattern for us custom blog builders to represent posts with an Entry model that contains two fields to hold the actual content. One field holds the "raw" content - typically in a markup format - and the other field holds the display content. Then we override the model's save method to process the markup content into HTML suitable for live content and stick that into the display field. So what I was looking for was an easy way to beef up the raw content field with some utilities so that composing entries would be a little easier.

I just happened to come across markItUp and was pleased to see that it would probably provide much of what I wanted and it looks like I'll be able to customize it to provide the shortcuts that are specific to my writing and styling preferences. I'm also a fan of jQuery. Obviously it would be preferable to just extend the admin since it's already so powerful so if I could just drop something in that would make editing a little saner that would seem to be a huge win.

Installing and Configuring markItUp!

I had a little confusion starting out because I followed the download link from the home page, which provides with you with the default set. markItUp uses the notion of "sets" to configure the specific markup language to work with. The default set is simply HTML. Once I found the downloads page I realized that I needed to also grab the Markdown set (my preferred markup syntax at the moment). From there installation proceeded well enough by combining referencing their sparse documentation with a few peeks into Firebug. In fact, I'm writing this post with the editor in place!

Extending the Admin

All we really need to do is drop a few javascript and CSS references and a little javascript snippet into the __ to turn our textarea field into a markItUp! editor. If you've never done any admin customization before, take a gander through the chapter in the Django book. I added a change_form.html template to /mytemplates/admin/article/entry. "mytemplates" is specified as a template directory in my Django settings, article is the app, and entry refers to the Entry model. The admin knows to look there first for any appropriate templates and load those rather its own template. Here is what my change_form.html template looks like:

{% extends "admin/change_form.html" %}

{% block extrahead %}
{{block.super}}
<link rel="stylesheet" type="text/css" href="{{MEDIA_URL}}css/markitup/markdown/style.css" />
<link rel="stylesheet" type="text/css" href="{{MEDIA_URL}}css/markitup/skins/markitup/style.css" />

<script src="{{MEDIA_URL}}js/jquery.js"></script>
<script type="text/javascript" src="{{MEDIA_URL}}js/markitup/jquery.markitup.js"></script>
<script type="text/javascript" src="{{MEDIA_URL}}js/markitup/markdown/set.js"></script>
<script type="text/javascript" >
   $(document).ready(function() {
      $("#id_body").markItUp(mySettings);
   });
</script>
{% endblock %}

A few notes:

The code snippet in the Django book does not include {{block.super}}. If you don't include this, then your change form won't pull in all of the helper scripts that provide some of the dynamic functionality you may rely on such as "pre-populate from". I don't know why they don't mention this in the book, but in most cases you'll probably want the admin to have the normal scripts available.
The "markitup/markdown/style.css" comes from the Markdown set and it provides the styling for the Markdown-specific buttons on the toolbar. The other one comes from the default set and provides some of the basic styling for the editor regardless of what markup set you happen to be working with.
I had to do a little find/replace on the css files to get the background image paths to match up to my configuration. The stylesheets assume that the images are all located in an images directory located at the root of the site. I house all my media (images,css,js) under a "site_media" directory and then I like to organize resources into subfolders so the markItUp! default scheme didn't work for me.
The "set.js" comes from the Markdown set. The defaults worked fine for me just to get everything going and I added a previewParserPath (more on that in a minute).
The little javascript snippet simply directs markItUp! to the textarea on the page and sets up the editor with the settings that are specified in "set.js". #id_body refers to the textarea corresponding to the body field on my Entry model.

This is all you need to do to get the editor working on a textarea on your admin change form page. The editor also has a "Preview" button (the checkmark) which will show the actual output in an iFrame below your textarea - a very handy feature! However you need to do a little extra work to have that functionality available.

Adding Preview Functionality

The editor will simply make an XHR POST with the markup content and dump the response back into the iFrame. So you just need to set up a view that will accept a data POST parameter, format it according to your preferred markup syntax, and return a full HTML page containing the output. Here is what a view could look like - add in your own exception handling and error checking to taste:

from markdown import markdown
from django.template.context import RequestContext
from django.shortcuts import render_to_response

def apply_markdown( request ):
    markup = markdown( request.POST['data'], extensions=['codehilite'] )
    return render_to_response( 'utils/markup/markdown/preview.html',
                              {'preview':markup},
                              context_instance=RequestContext(request))

You'll notice that I pass the codehilite extension to markdown to handle making code snippets all nice and pretty. You may not need this in which case you can simply omit the second parameter. I am using a RequestContext since I would like access to the MEDIA_URL in the template. This makes it easy to include the special stylesheet utilized by codehilite in a portable manner (syntax.css). Here is the template:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<head>
    <title>Markdown Preview</title>
    <link rel="stylesheet" type="text/css" href="{{MEDIA_URL}}css/syntax.css" />
</head>
<body>
    {{preview|safe}}
</body>
</html>

The last thing to get this working is to add the path to your view in the previewParserPath in the set.js. Now you can simply hit the Preview button and get an idea of what your final output will look like. One minor annoyance is that once the Preview iFrame is open there does not appear to be an easy way to close it and what will happen is that as you continue editing your markup the iFrame will refresh whenever you hit Enter.

Conclusion

One issue worth a little attention is that if you are using the built-in development server to serve media with the Django static media view, adding in the markItUp! editor will add a lot of overhead since it pulls in a few extra javascripts, a few extra CSS files, and fair amount of small graphics to provide the toolbar. As the Django documentation clearly states, the development server was not designed with media serving in mind. You may find that your admin pages bog down quite a bit on loading. If this bugs you, I recommend taking a few minutes to set up a local media server for yourself. That way you'll get the benefits of the debug environment combined with the snappy performance of a dedicated file server.

markItUp! has already provided some tangible benefits to my work flow and I am looking forward to doing some further customization to make it even more useful. In a future article I plan to cover any useful bits I come across. markItUp! may not be for everyone. In particular there are some known issues with how Safari handles events on Ctrl and Shift keys. Also, this is still beta software so use at your own risk. As I mentioned, the documentation could benefit from a little more detail and some more code examples.

DjangoGears: Django and TurboGears to Merge

Please note that this entry was created for April Fool's Day (April 1). It is not a factual story. Thanks for visiting :)

The core developers for both Django and TurboGears have been holding discussions on the IRC channel #railsenvy for the past several weeks about plans to merge Django and TurboGears into a single code base. Everyone is in agreement that having too much choice in the community for web frameworks is dangerous for users and detracts from the Python community. The main cause for concern is the continuing growth of Rails and the worry that Erlang and/or Smalltalk frameworks will hypnotize developers into dropping Python altogether. Not to mention that Perl 6 is due to ship anytime in the next five years. Coincidentally, Larry Wall also joined into the discussions during the final phases and practically begged the group to get the new uber-framework standardized on the Parrot virtual machine, which they agreed to.

They are still working out the final details but here is what is known so far:

Much of the core functionality will be transfered to the client-side in order to alleviate performance problems. They are still debating over whether any of the current AJAX libraries will be up to the task or if they should just roll their own.
The ORM will be redesigned from the ground up. Neither Django's ORM nor SQLAlchemy represent the quality of what developers will want going forward. The queryset-refactor branch has always had a hush-hush underlying motive of being a practice round for this work. One thing that was learned is that ORMs are just too difficult to write and even more difficult to use. This is largely due to inherent flaws in the expressiveness of SQL and the group has already worked out a new and improved way for dealing with databases that should send shockwaves through the industry. The new language is sytantically based on COBOL and in fact they have found that much of the COBOL implementation provides the majority of what is needed.
The current template system in Django falls far short of being usable. The Django developers have long admitted that not having access to the full Python interpreter from the scope of the template is a serious deficiency. PHP developers assigned to Django projects have been known to suddenly become afflicted with all sorts of medical problems when they discover this weakness. TurboGears has already solved this problem by utilizing up to 6 or 7 independent templating engines simultaneously. However, none of these other engines will match the innovation of the custom engine they are creating just for this project. The syntax resembles Lisp and will consequently be heavily functional based. One of the coolest features in my opinion is that you can also create blocks of LOGO code (the turtle style) for drawing boxes, lines, and other shapes on your page. This should be a tremendous benefit since doing styling with CSS is difficult and non-intuitive.

This is all seriously exciting news. They should be making a formal announcement soon but they are waiting until the announcement page can be built on the working version of the new framework.

Two New Django Community Sites

Two new Django-powered sites entered the tubes this week that should be beneficial to the Django community: DjangoFriendly and DjangoPost.

DjangoFriendly

DjangoFriendly is a site that provides a list of web hosts that provide explicit Django hosting. A simple voting interface common to Web 2.0 applications allows users to show their indicate their support or dismay for the quality of service provided by the various hosting companies. Built by Ryan Berg, the site has a slick design capturing the green shades that we all know and love from the official Django sites (home and book).

At this time the site does not accept submissions for new web hosts. Ryan generated the current set by mining the data on the Django wiki. A tremendously valuable feature is user-submitted reviews. I'm both pleased and surprised to see that WebFaction is (currently) at the top of the list. I've been with them for a while and have always been well pleased with the quality of support and the service in general.

In true Django fashion, Ryan took advantage of a few exisiting apps to provide the bulk of functionality: Jonathan Buchanan's django-voting and django-tagging, and James Bennett's django-registration. Ryan, like Jeff Croft, is one of those self-professed non-programmer designers who are a testament to what can be done with dynamic languages like Python and frameworks like Django with a little desire.

See Ryan's announcement post

DjangoPost

DjangoPost is a Digg-style site with a goal of focusing solely on Django-related news. This should be a great resource both for Django fans looking to keep up with the latest news as well as writers targeting the Django community. The site is created by Aware Labs who also created the Arkayne portal system.

The design is bland but purposeful and categories have been set up to help differentiate the content. In particular the styling of the voting controls and popularity counts seem a little out of place but that won't detract from the functionality of the site. The site offers a widget that can be embedded in any site and they are also making a code available specifically for Wordpress sites. In addition to filtering results from established sites like Delicious and Reddit, DjangoPost should provide a convenient central location for finding Django specific content.

See the announcement on Aware Labs

PyCon 2008: Django Now Plays on the "Dark Side"

Today I witnessed Django running on something other than CPython ...and that something wasn't Jython. The virtual machine in this case was Microsoft's DLR running IronPython. This is exciting stuff! I attended the "IronPython: The Road Ahead" talk given by Jim Hugunin with some assistance by Dino Viehland who is the lead developer for IronPython at Microsoft. For me, this was actually one of my favorite talks of the conference and was a nice cap to the official portion of the conference. Jim really brings a lot of energy and it was easy to see that the IronPython team is really excited about the work they are doing.

For the demo, Dino showed us the latest Django release (v0.96) running on IronPython 2.0 Beta 1 (which was just released on Friday). He did have to make a few patches to get the demo running. Naturally they chose to use MS SQL Server for their database and Django does not support that database by default. A handful of one or two line changes to the Django source got it working for IronPython. Additionally, there was another one line change or two that had to do with handling unicode properly. He noted that with the trunk of Django that may no longer be an issue since Django now supports unicode throughout. I spoke to Dino following the talk and he hopes to get the diffs he made available ASAP. They also would like to get IronPython working with Django trunk.

Dino demonstrated the simple poll application that we're all familiar with from the Django official tutorials. He started with the vanilla version as would result from following the tutorials and then followed it up with a spruced-up version that included some video and image backgrounds, nice UI effects, and rich-client dynamic updating of the voting results. All of this was of course accomplished with a minimal amount of Python code.

Jim also showed a number of demonstrations – all focused on Silverlight capabilities. From what I've seen of Silverlight so far, it looks like very cool technology. If you haven't taken it for a spin yet, you might not be aware that Silverlight is a cross-browser and cross-platform plugin. It runs in Internet Explorer, Firefox and Safari and is supported on Mac. Novell and the Mono Project are also making a port available for Linux called Moonlight. While Microsoft does not officially support Moonlight, they have contributed some help to Novell and even more importantly have made some of the codecs available. Licensing remains a huge stumbling block for media distribution on open source platforms and Microsoft is helping to ensure that their Silverlight technology will enable a similar experience in a variety of situations. Silverlight will also be available on Nokia but so far is notably absent from another very popular mobile platform. This gave them a rare opportunity to criticize another company for promoting a closed platform.

As I said, Silverlight looks like some very cool technology and should be a major player in evolving the consumer computing experience. Jim mentioned that he was not previously familiar with Django and was pleasantly surprised after seeing Dino's demo code about how easy it was to create a web service exposing some data as JSON. It was merely the simple application of Django's JSON serializer to a queryset that we Djangonauts are familiar with. A word of caution for early adopters and bleeding-edge pioneers: I spoke with Dino after the talk and he said that data binding is not yet functional for IronPython in Silverlight. If you're not familiar with .NET parlance, “data binding” is the terminology for what is analogous to template tags and variables in Django. Simply put, data binding allows you to associate fields of a data set to controls (widgets/elements) on your page.

OK, so the title to this article was a bit of a shot across the bow toward MSFT. Personally, I'm neither a Windows fan boy nor am I a hater. In my experience many who are entrenched in open source (or more generally non-MS) technologies view Microsoft with a wary eye at best. Although a little late to the party, Microsoft is starting to change their tune. They are definitely making efforts to play nicer in the general developer communities. I expect that if I am inaccurate in my legalese here someone will kindly step up and correct me, but IronPython is released under the Microsoft Public License which is now OSI certified. The fact that they took some effort to get Django running on IronPython demonstrates that they are interested in making sure that IronPython is truly Python. This is quite a departure from the past for a company that is well-known for starting with a piece of standards-based technology and mangling it just enough to break standards compatibility and achieve platform lock-in.

One thing Jim mentioned that was a high point for him was when new Chief Software Architect Ray Ozzie took the stage at Mix and mentioned IronPython (about 47 seconds in) as an exciting new development for Microsoft. Certainly as IronPython continues to mature it will open for the door for Python acceptance into organizations and businesses of all shapes and sizes who already have a significant investment in .NET.

PyCon 2008: Django (Pre-) Announces Nonprofit Organization

Adrian Holovaty began "The State of Django" presentation by saying that at the conclusion there would be an announcement about Django. Jacob Kaplan-Moss informed the crowd that they were in the process of forming a Django non-profit organization. This will be a great step forward for the project in many ways.

There were not a lot of concrete details since they are early in the process of getting this setup, but they wanted to let the conference attendees in on the great news. The most obvious benefits are that there will now be a single legal entity to shepherd the source code. They will be able to accept donations in order to help the project grow. The existence of a legal entity will provide a single point for individuals, communities, and enterprises to go to get support. Such an organization will also provide a central point for reaching out into the broader community and fostering mutually beneficial relationships.

This is great news for fans of Django and for the larger Python community as well!

PyCon 2008: State of Django by Adrian Holovaty

Adrian Holovaty took the stage at PyCon 2008 to give a summary of the current state of Django. Jacob Kaplan-Moss also jumped in to answer a few questions. Adrian recapped what major developments have been occurring in the world of Django during the last year and gave brief overviews of the important developments that we can look forward to on the march toward a 1.0 release.

To begin, Adrian touched on the unique role PyCon has played with respect to the realization of Django and the popularity it has gained. It was at PyCon that they originally started showing the code around and were encouraged to make it available as open source. They feel that they have a special connection with PyCon in that it is a great time to connect with the community at large, generate new ideas, and advance the code base via sprints.

It was noted that at last year's PyCon the current Django release was v0.96 and at this time it is still the recent release. In the Django community, it is not uncommon for developers to run the trunk or fairly recent versions - even in production. He acknowledged that in some development cultures, running trunk is frowned upon and that fact alone keeps some companies and developers from adopting Django. The Django developers do not have a hard scheduled date for releasing v1.0 and he apologized to those who work at companies that refuse to adopt Django until it reaches that status.

Reviewing the Last Year

Among the various features, tweaks, and fixes that have been tackled during the last year, three were notable:

Unicode support throughout. All text data within Django is handled as Unicode now. If any part of the framework gives you text data back, it will be in Unicode format
Auto-escaping in templates. Data output in templates (ex. {{ somevar }}) will be escaped to convert unsafe characters to HTML entities. This is a safety feature and it alleviates developers from having to remember to explicity escape data that could have come from user input. Of course, there is an option to indicate that a piece of data does not need to be escaped and you can also disable escaping across larger scopes.
Oracle support was added a few months ago. This should make Django more attractive to enterprise-y developers and obviously for those who use Oracle as their database of choice.

GeoDjango got a nice plug. It is a branch of the Django project that is able to make use of geospatial extensions so that you can add location or distance based capabilities to your objects. For example, find all objects within a radius of a particular object or find the geographic distance between two objects. The guys at GeoDjango have done a great job keeping the branch up to date with trunk. One nice side effect of the great work of GeoDjango is providing a compelling draw for GIS professionals to invest in both Django and Python.

There were two development sprints in the past year: Sept. 6 and Nov. 11. There will be another sprint at PyCon 2008 following the main conference and starting on Monday. The sprints have been greatly beneficial to the project as a whole in terms of getting features implemented, bugs fixed, and new ideas fleshed out. As of morning, Friday March 14, there had been 2432 checkins to trunk during the past year. Much of that was due to the wonderful support provided by the community.

Some notable sites beneficial to the community were launched during the past year:

djangosites.org - a directory for listing sites created with Django
djangosnippets.org - a collection of community contributed snippets, recipes, and patterns
djangogigs.com - Django based job listings and a place for Djangonauts to list themselves
djangopeople.net - a site where you can list your location and connect with other Djangonauts in your area
djangobook.com - the online version of Adrian and Jacob's book. A tremendous learning and reference resource for the community

Coming Soon to a Trunk Near You

QuerySet-Refactor

The queryset-refactor branch represents a major refactoring of the database query logic. If you've ever poked around in Django's internals, you may have come across query.py which is a behemoth of a file. The main focus of this branch is to clean up code, address some deficiencies in the current API and provide the much requested model inheritance capabilities.

Newforms-Admin

The newforms-admin branch is a rewrite of the admin app to utilize newforms. A lot of effort is being made to ensure that the admin provides more hooks for developers so that the admin is more easily customized. Another important aspect of this branch is the decoupling of admin metadata from models. This means the nested Admin class will no longer be used and this will help to promote separation of concerns. One nice feature that will come with this branch is the ability to declare different admin sites on a per model basis. This will provide a lot more flexibility from an administration perspective and make it easier to allow different users/groups to manage various aspects of the site.

One feature on the table that the developers would like to get in for the 1.0 release is model validation. The idea is that models that are instantiated from data should validate that data before attempting a save to the database. Without this important step it is possible for the stored data to lose integrity and get your database into a bad state. Adrian admitted that they don't yet know what the best implementation strategy for this is. Newforms already has a validation layer so there are questions about how much if any of that code should be utilized or if perhaps all validation logic should be refactored out into a cloud that can be utilized by the various pieces of the core. They are counting on the upcoming sprint to help produce a roadmap.

Finally, they made a surprise announcement at the conclusion of the presentation.