Definitely +1 to Mike's post. Lots of great advice. I'm ashamed to admit that I'm usually the sort who goes about projects without any written planning what so ever. Generally I spend some time forming an idea in my head as to what I'd like and what I want to implement, but often that gets twisted and distorted in the details until I'm slogged down in figuring out how to jury rig in a feature that I should've seen coming but didn't.
I might have to try penciling out the project if only as an exercise and experiment in trying a slightly more disciplined approach. So ... I feel slightly guilty about asking this, because I might as well be throwing napalm on the stove but which editors/IDEs/whatever do people prefer for their Djangoing? Personally I've been a long time user of jEdit, just because it provided just enough for comfortable and quick editing without being feature rich to the point where I feel like I should be doing things the IDE's way instead of my own way. Lately, however I've been learning and using vim and I think I'm falling in love. I know it's already replaced nano in my toolbox for any quick edits that I have to do over ssh. I've also been combining it with screen locally to spend my code editing time in keyboard- shortcut bliss. I'm a big fan of being able to code for hours without having to go to a mouse; I don't know what that is, but it just is. Maybe things are just more fun in a term. On Oct 19, 11:06 am, Mike Ramirez <[email protected]> wrote: > 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 > > > > > > > -- > A kind of Batman of contemporary letters. > -- Philip Larkin on Anthony Burgess > > signature.asc > < 1KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
