I see I broke off mid thought, my individual py files got small and I didn't have to do any of my own sub-file discovery logic to do something like "models/foo_models.py", "models/bar_models.py"... There is nothing preventing tight foreign-key relationships across apps. In reality, all of the tables are in the same database.
I also use:
class Meta:
app_label = 'major_app'
in the model class of each sub_app, so that all of the admin pages are grouped
together.
Brian
Brian Schott
bfsch...@gmail.com
On Jan 10, 2012, at 1:46 AM, Derek 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.
>
smime.p7s
Description: S/MIME cryptographic signature
