I am working to build a django application and will relay on a lot of JavaScripting using JQuery. When using heavy javascripting I will require to pass some variables on run time and am trying to keep my code neat without inline js.
My first question: Is there a best practices for how to manage the js libraries that are built over time? my second question, I was thinking to create an application inside my project and host templates with .js extension and render the views with javascript mime types. Is this by any chance a good practice?
regards,
I think, you should take a look at JavaScript frameworks that implement some sort of model-view-controller pattern on the client side (if you haven't done it already).
Here is a quote from a discussion about one of these frameworks, backbone.js. I think it's relevant to your question about management of javascript libraries.
<...> if you have an application with a lot of JavaScript interactivity, or a single-page application where the entire interface is driven from JavaScript (this is the case for us), then it helps to structure your client-side code with a little more oomph than just jQuery provides.
Taken to the extreme, in our case, the DocumentCloud workspace is effectively an empty body tag, and all of the HTML rendering and interesting logic happens in JavaScript models and views -- you never have to refresh the page. The server-side Rails code becomes smaller and less complicated, essentially delegated to performing validations and authentication and serving JSON to the client. Think GMail, or New Twitter, or 280 Slides...
Yes, Rails were mentioned, but wait, architecture stays the same if you're using Django (or Flask, or any web framework at all):
Server side implements the API. It basically provides, accepts, validates serialized data.
piston
or django-tastypie
are good for this, for instance.
Client side makes necessary AJAX requests to retrieve the data, displays views of the data, renders templates, makes requests to save the data, etc.
For example, Backbone.js provides, among everything else, a Model prototype. You can extend it (or subclass, if you're using CoffeeScript) and tie to your server-side model by providing an url of the corresponding tastypie
resource. After this, you need not bother about synchronization: you just do my_model.save()
, and Backbone.sync
behind the scenes will make AJAX request and update server model instance.
I've recently started to use brunch. It basically provides a skeleton for the rich application, combining CoffeeScript as better JavaScript, backbone.js
for MVC classes, eco
for javascript templating, stylus
as css preprocessor, and other good things (and providing convenient command-line interface: brunch watch
, brunch build
). I suggest to take a look on how files in brunch projects are organized.
Django at the moment doesn't make it easy to manage heavy client side application. You need to figure out yourself how, say, you should organize libraries.
At the same time, many building tools that minimize and optimize scripts and stylesheets (like requirejs
) are somewhat hard to integrate into the usual Django project development workflow. And you most probably will need one of these tools, if you plan to create rich javascript app.
Creating an app inside your project is an option, but, I think, it would complicate things a bit. You already have two more or less separate apps, so why not go ahead and separate concerns further—just work with two actually separate projects? One project would be Django-based for server side, and another, for example, brunch
-based, for client side.
We started doing this with our latest project, and I personally think that makes things more manageable and easier to work with.
Update: I think this post does pretty good job on summing up pros and cons of keeping projects separate.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With