I haven't found any 'best practices' for Python other than PEP-8 or the older http://www.python.org/doc/essays/styleguide.html.
Django kind of pre-defines a general best practice of project layout, but anything outside of models, tests & fixtures, templatetags, et. al. is up to you (views and settings are not 'required' to be where they are). Anyway, it's kind of discomforting at first, coming from J2EE-land where everything is laid out for you in the core J2EE Patterns book. "Here are you DAOs, there are your Business Delegates, and over there's where you keep your transformers and your DTOs"... In Python/Django, you have to think a little bit more about how you want to lay things out and where they belong /in your project/. So there's not that uniform inter-corporate architecture consistency you find (or at least I found) when bouncing around in contract gigs for larger corps. If it helps, my progression went first from breaking everything up into small chunks in lots of files and apps (a la one class per file Java), to now having much bigger modules holding lots of related concerns (classes and functions). I think that it's more common in Python to do this, and it's a lot easier to remember where stuff is. for what that's worth... On Apr 3, 11:52 am, bcurtu <[EMAIL PROTECTED]> wrote: > Thanks Doug, > > Well, yes, I think it's pretty easy to switch to this philosophy, even > it's hard to come back to java again! > > I will follow my model 1, because it's generic code and it could be > reusable. > > What about a good practices reference guide... Any suggestion? > > On Apr 3, 4:54 pm, Doug Van Horn <[EMAIL PROTECTED]> wrote: > > > On Apr 3, 9:19 am, bcurtu <[EMAIL PROTECTED]> wrote: > > > > Hi again, > > > > I come form j2ee world, this is my first project in Django and usually > > > I feel a bit lost about general concepts. > > > > My project has bit too much business code, it's a kind of datamining > > > tool. I have created a set of functions but I'm not sure where the > > > "best practices" say I should place them... > > > > 1.- In the same folder as my app (package) is, in a different file: > > > app1/ > > > __init__.py > > > models.py > > > views.py > > > datamining.py > > > > 2.- In the same models.py or views.py file?: > > > app1/ > > > __init__.py > > > models.py > > > views.py > > > > 3.- In a new app (app)? > > > app2/ > > > __init__.py > > > datamining.py > > > > Thanks for your advice... and, do you know any good practices > > > reference for django? > > > I came from the same world (J2EE, many years), FWIW. > > > I'd choose 1 or 2. In an e-commerce app I've been working on, I have > > lots of Google, PayPal, and Authorize.net code that have their own > > modules (google_checkout.py, etc.) that reside in the app1/ folder. > > These functions are used by the views to check a user out. > > > I also have lots of 'business logic' code around Cart -> Order -> > > Invoice transitions, but that code is in my models.py file, woven into > > Managers and Models. Again, used by the views. > > > My rule of thumb is that if it's data related, it belongs in the > > models.py file, if it's workflow/control related, it belongs in the > > views.py file. Anything utilitiy-like (which kind of implies > > potential reuse), it belongs in it's own module. > > > When you use the term datamining, it kind of tastes like Manager code > > (cross record stuff). If you're doing more cross-model-cross-record > > stuff, it's probably it's own module. > > > As a former J2EE guy, it took me a while to get past the need to > > package everything in it's own space (1 class per file and all). I'm > > much more comfortable with the module approach now. > > > doug. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
