On Saturday 17 October 2009 21:55:39 Shakefu wrote: > So my questions are simple: > > What are your opinions on the best methodologies and practices for > developing django apps and projects? > > What sort of planning do you do for an application or project? I've been thinking about this and first off, I don't think there is a best practices for django apps and projects in terms of how you design a website. Which your questions seem to point to.
I think the best practices you're asking for are generic enough that they are effective with most web design projects regardless of language/framerowrk. For example the steps I take are first identify the goal project, then figure out what applications are required to make that goal a reality. At the application level, I start with the models and what basic data do I need to collect for the app. Then I go to the forms and create those as needed to collect data. Next to the urls and start mapping out urls to the data that should be displayed, collected, etc..., then create the basic views. At this point the application should take shape and you'll know what it'll provide. From this point on, I start looking at what I'm missing in terms of the model fields and then decide if I need/want context processors, template tags and filters for the data and for data I want to be available regardless of the view. In say a gallery app, I'll add in template tags that display random images or a list of images, that can be used anywhere in the site. Then it's on to clean up. I take these steps per project/app normally. > What development techniques do you use to help conceptualize an > evolving project/app? > > So what works for you? Why? What doesn't work or what stumbling blocks > do certain routes present? Well, I start with drawing up a mock up of the index page layout (the basic layout used through out the site). Then write out (psuedocode/flowchart) what I think is needed to make the site function per the specs, using the order outlined above. This gives me a great idea of the full scope of the project before I type one thing or an image is made and I can minimize the additions of fields in the models (mentioned in an earlier email) later in the project. What doesn't work for me and is probably the most annoying and most used system is to go at it on the fly, with little or no planning or written plans before you start to code. Eventually you'll start to go out of scope and add more things within spec, changing the deployment time usually. With a plan, I tend to minimize 'scope creep'. Outside of this, there are django specific things you should be aware of. Someone mentioned in a thread a few days ago (can't find it now) talking about two view functions, where you have your view function setup the data for that specific view and then a utility function that builds your context, template and returns the response. I think they were putting a middle man between the render_to_response shortcut and the actual data gathering/building for the view. To see what I mean, take a look at djangobb it uses a decorator to do this. Djangobb also use a build_form function that takes a form object and returns an instance of it, either initialized with post/get data or without it. In the end most of the best practices with django resort to utilizing the DRY philosophy more than anything. But at the same time you lose some flexibility or atleast readibility if you combine multiple methods. So I go with flexibility over DRY, because it is more important to me. This is why I don't like the two view idea, outside of using render_to_response. Personally I've found by reading django-registration and DjangoBB that you can find a lot of good/best practices for building your app/project. Especially django-registation and how it defines it's view functions, the args passed to each function like extra_context and template name, this way it can be over written in the urls at allows the most flexibility for other developers. The one item I'll take away from djangobb to other projects is it's per app settings usage. Until then I had been using two global settings file, a settings_local.py with settings specific to the deployment such as database info, and the regular settings.py file with settings global to the project regardless, like installed apps. With app specific settings sprinkled between the two. These are just a few of the ideas I've seen and utilize. The general rule of thumb I use is: K.I.S.S. Keep It Simple, Stupid. Mike > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "Django users" group. To post to this group, send email to > [email protected] To unsubscribe from this group, send email > to [email protected] For more options, visit this > group at http://groups.google.com/group/django-users?hl=en > -~----------~----~----~----~------~----~------~--~--- > -- A kind of Batman of contemporary letters. -- Philip Larkin on Anthony Burgess
signature.asc
Description: This is a digitally signed message part.
