Cal I agree that its true that having more experience allows you to build better web apps and get smarter about how you do that. But I disagree that someone with that experience cannot share some or part of the "why and how" that is done. And I hope someone will be able to :)
Derek On 10 January 2012 13:01, Cal Leeming [Simplicity Media Ltd] <cal.leem...@simplicitymedialtd.co.uk> wrote: > I've hit this same problem myself many times. > > Ultimately there is never any one answer - you can split out functionality > into individual modules, but there has to be a good use case for it, > otherwise the overhead has a negative impact. > > You also have to take into consideration the re-usability of what you are > splitting out, and if something is split out, then it has to be treated as a > standardized module which is kept backwards compatible for everything. > > It's not just a case of having a standardized directory layout, the entire > use case of the project will determine the layout - you can follow 'sane > principles' such as naming convention etc, but the actual splitting of > functionality is really up to the developer (and isn't really something that > can be taught - it's more of an experience thing). > > Personally, I found that using 'MultiHostMiddleware' has been an absolute > life saver for splitting out sites within a single project - check it > out: http://code.djangoproject.com/wiki/MultiHostMiddleware (I just went and > tidied it up a bit). > > Just my two cents worth! > > Cal > > On Tue, Jan 10, 2012 at 6:46 AM, Derek <gamesb...@gmail.com> wrote: >> >> Brian >> >> That is useful "generic" advice and a topic I am very interested in - >> how to break up an "enterprise" type of application into smaller apps >> (to enable distribution of sub-sections to different types of >> audiences) while at the same time maintaining tight coherency among >> closely-related data sets. In this case there is a typically a "core" >> data set and then many other more peripheral ones that all need to >> connect to the core. I have not yet seen any example of such a design >> process - or even a set of principles - which describe *how* to >> achieve such a design. >> >> Derek >> >> On 9 January 2012 18:18, Brian Schott <bfsch...@gmail.com> wrote: >> > My advice is If you find yourself breaking models, views, utils, etc. >> > into separate files within an app, you should really consider breaking your >> > app into multiple apps. I hit this myself in or own project and found >> > myself dealing with the auto registration functionality for admin.py, >> > tasks.py, and a bunch of other too-large files. I bit the bullet and broke >> > things out and my import/discovery headaches disappeared. My individual py >> > files got small and >> > >> > +--major_app >> > +--docs >> > +--templates >> > +-- (img, js, css, base.html) >> > +--projects >> > +--dev >> > +--test >> > +--deploy >> > +--apps >> > +--sub_app1 (create with startapp command) >> > +--models.py >> > +--tasks.py >> > +--templates >> > +--tests.py >> > +--urls.py >> > +--views.py >> > +--... >> > +--sub_app2 >> > +-- ..... >> > >> > I put this in the top of my settings.py files down in projects/dev or >> > projects/test, or projects/deploy so that the apps just get discovered. >> > >> > # the base directory is up two levels from the project >> > PROJDIR = os.path.abspath(os.path.dirname(__file__)) + '/' >> > PROJNAME = PROJDIR.split('/')[-2] >> > BASEDIR = os.path.abspath(os.path.join(PROJDIR, '..', '..')) + '/' >> > APPSDIR = os.path.abspath(os.path.join(BASEDIR, 'apps')) + '/' >> > >> > # add apps and projects directory to path >> > sys.path.insert(0, PROJDIR) >> > sys.path.insert(0, APPSDIR) >> > >> > Brian >> > >> > Brian Schott >> > bfsch...@gmail.com >> > >> > On Jan 7, 2012, at 2:24 PM, IgorS wrote: >> > >> >> Below is my current structure. I am new to Django and probably missing >> >> something... Restructuring an application somewhere in the middle of >> >> the development cycle is more expensive than just having the "right" >> >> layout from the start. Especially if this is possible. I consider a >> >> small overhead at the start being better than a great rework in the >> >> middle (yes, i am aware of the minimal viable product concept :-) >> >> >> >> app >> >> +--models >> >> ---abstract_base.py >> >> ---core.py >> >> ---... >> >> +--probe >> >> +--static >> >> ---css >> >> ---js >> >> ---images >> >> +--templates >> >> ---base.html >> >> ---... >> >> +--tests >> >> ---test_users.py >> >> ---... >> >> +--utils >> >> +--views >> >> ---__init__.py >> >> ---app_settings.py >> >> ---context_processors.py >> >> ---middleware.py >> >> ---urls.py >> >> >> >> Thank you, >> >> -igor >> > >> >> -- >> 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 >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > -- > 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 > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. -- 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 django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
