Django is clever enough to put it together for you.
This can be a huge time saver.
Django doesn’t do everything for you — you need to tell it which of your models should be accessible via the administration interface.
You also have some control over how your models are turned into forms and suchlike by specifying things like field types and default values.
Here is some code for creating a model and adding it to the administration interface:class Room(models.
Model): name = models.
CharField(max_length=30) can_draw_on_walls = models.
register(Room)Note that this is code is very minimal, the admin interface can do a lot of things and be customized in all sorts of ways.
That said, tweaking the admin interface can take a lot of time so if you want something very fancy then Django and Pyramid are actually tied on this point.
Ease of AJAXPyramid wins this one.
Use of decorators and XHR views make it very easy to get AJAX requests to go where you want them.
Explaining XHR, decorators, or AJAX is way outside the scope of this tutorial but I assure you the explanations are out there.
In Pyramid, to add an xhr route you could do something like this:config.
add_route('test', '/test', my_view, renderer="json", xhr=True)Or this:@view_config(.
xhr=True)If that doesn’t make sense don’t worry.
If you choose to go with Pyramid then this will look pretty straight forward once you get into things.
Django does not have a comparable xhr mechanism.
Code LayoutDjango makes use of things called applications in order to make it easy to plug new capabilities into your product.
This is very good in a way because it encourages developers to write code that is self-contained.
It also makes incorporating applications from other sources pretty straight-forward and reading other people’s code easier.
Django has a bootstrapping mechanism for creating new applications within a project.
py startapp booksThis command creates a new application called books within the current project.
Once an application is created it needs to be installed, that is, the project must be updated so that it 'knows' about the new application.
This is done by updating the project settings file.
If this makes no sense to you, I will again refer you to the Django book.
Pyramid, on the other hand, lets you do whatever you want but has a few conventions in place.
So that is a pro and a con.
Pyramid’s code layout conventions are largely encouraged through use of scaffolds, a sort of bootstrapping mechanism.
When starting a new Pyramid project you can either make all your files from scratch (which is hardly ever worth the time) or create a base project to work from through use of a scaffold.
There are a number of different scaffolds that come standard: the alchemy scaffold is optimized for SQLAlchemy; and the zodb scaffold for ZODB.
There are also various scaffolds available for download.
To create a new project using a scaffold we use pcreate from the command line.
Like so:pcreate -s alchemy hello_alchemyThis creates a project that has all the bits and pieces in place for creating an SQLAlchemy based Pyramid application, and names the application hello_alchemy.
In summary, Django is pretty strict here, and Pyramid is not.
Django forces you to stick to certain conventions that can be confusing for new programmers, and Pyramid give you the option of which conventions you would like to stick to (which can also be confusing for new programmers).
Pyramid’s approach here is another expression of the flexibility it provides.
SQLAlchemy SupportSQLAlchemy is a very powerful thing, a lot of very clever people think it’s the best ORM around.
If you choose Django you choose not to use SQLAlchemy.
It is only a big deal if your application is very (SQL) database intensive — if you want to do complicated queries in a sane way.
On the other hand, if your app is simple then SQLAlchemy won't be a big help, but it doesn’t hurt to have it.
Community and SupportThis one is a tie.
The communities that use and support both Pyramid and Django are huge.
ConclusionPersonally, I prefer Pyramid — the flexibility it allows is very appealing and makes it quite fun to work with.
But there are definitely reasons to use Django instead.
The two frameworks both deserve and have huge followings.
It is pretty hard to say which one is better.
They were designed with similar end goals and fill the same niche, but their different philosophies are apparent in almost every aspect of their respective designs.
Pyramid is great because it is flexible and Django is great because of its batteries included philosophy.