Re: Directory layout for a large Django application (not project)
Thank you, Tom, for your thorough explanations (and moral support :-) The situation is much clearer now. I hope this topic will be useful for those who will later on join the wonderful Django world. Thank you, Brian, for sharing your layout and experience. Actually, I had been thinking about having multiple “small” directories (or sub- apps) with small files – one models file, one tests file, etc., but have never seen it implemented or discussed and was not sure if it was possible and/or reasonable. I just wish your project was an open source so I could learn more :-) Thanks to everyone who participated in this discussion. Best wishes, -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.
Re: Directory layout for a large Django application (not project)
That's a good point - although I can't think how to explain it in words..
Makes me wonder if I should do a blog post about this infact... *adds into
todo list, amongst the other 9000 tasks he has* lol.
On Tue, Jan 10, 2012 at 6:54 PM, Derek wrote:
> 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]
> 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 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 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
> >> >>
Re: Directory layout for a large Django application (not project)
On Tue, Jan 10, 2012 at 6:13 PM, IgorS wrote: > First of all, thanks a lot to everyone who replied :-) > > Tom: > > As i mentioned, i am new to Django and could be missing big parts. > Please do not hate me too much for my naivete :-) Never apologise for trying to learn :) It took me a really long time to get to grips with how apps should interact with projects. You've avoided many of the problems I encounter with my production sites :) > But I have some doubts regarding the templates. And the doubts come > exactly from that [explicit vs. implicit] perspective. Why not making > it more explicit? I mean to change it in a way that there is no need > to relay on the order in which Django searches for the templates. The > order is defined at the project level and this unnecessarily couples > my application with the project. Python programming tends to have at least two golden rules*: 1) Explicit is better than implicit 2) Don't repeat yourself Sometimes I feel that that these two rules are at odds with each other, and this would be one of those cases. It would be more explicit to manually resolve the template that you want in the view, but then we would have to manually resolve which template in every view :) So instead, the best way is to explicitly include the app name in the template name, by keeping templates in a subdirectory named after the app, and allow simple template loaders to find it. This actually reduces coupling, as another poster has alluded to, as you can override a specific app's template on the project level. As an example, when using django's admin app, you can override specific templates by creating the appropriately named template in your project template directory: https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#overriding-admin-templates If the view manually resolved the template to use, you would need to provide a mechanism to allow a project to override an app template. Remember that the app author is not necessarily the project author. > The only two places where the templates are referenced are the views > and other templates (in the “extends” tag). Please correct me if I am > wrong. Well, technically templates can be used for generating any textual content, for instance I use templates to generate email contents in backend (non website driven) processes. But yes, pretty much - and the use is pretty much the same (render_to_string() rather than render_to_response() or render()). [...] > Am I digging in a wrong direction? Is it easier to just rely on the > Django's template scanning order and to forget the whole thing? > What do you think? Yep, I think that the current 'standard' of prefixing your templates with your app name is pretty good. There are no major flaws in how it currently operates, and it offers a lot of flexibility. Cheers Tom * I always add this rule to any golden rules: 3) You don't always have to obey golden rules! -- 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.
Re: Directory layout for a large Django application (not project)
On Tuesday, January 10, 2012 at 1:13 PM, IgorS wrote:
> First of all, thanks a lot to everyone who replied :-)
>
> Tom:
>
> As i mentioned, i am new to Django and could be missing big parts.
> Please do not hate me too much for my naivete :-)
>
> The approach you suggested regarding the static files seems to be
> reasonable. Especially considering that the static files will
> eventually go to a separate server.
>
> But I have some doubts regarding the templates. And the doubts come
> exactly from that [explicit vs. implicit] perspective. Why not making
> it more explicit? I mean to change it in a way that there is no need
> to relay on the order in which Django searches for the templates. The
> order is defined at the project level and this unnecessarily couples
> my application with the project.
>
>
A big reason to keep it the current way, is that typically the project level
templates will override app level templates. This let's you create reusable
apps and distribute them with default templates, but allow other apps or the
project itself to override those templates without having to modify the
original app.
>
> The only two places where the templates are referenced are the views
> and other templates (in the “extends” tag). Please correct me if I am
> wrong. Making it more explicit in the views is simple. E.g., it can be
> done like this:
> template = app_settings.path_to_template('base.html')
> return render_to_response(template, …)
> Here app_settings.py is a settings file that stays in the
> application's root folder; and path_to_template is an application-
> specific function, which returns absolute path to the template (using
> os.path and the name of the app's folder).
>
> Dealing with the templates that reference other templates (in the
> “extends” tag) seems a bit trickier... One way that I found is to use
> a variable in the “extends” tag. But that will require some code in
> the application-specific context processor, which in turn will need to
> be specified at the project level in settings.py in
> TEMPLATE_CONTEXT_PROCESSORS.
> In that case I can do something like this in the templates:
> {% extends _TEMPLATES.base %}
> where base is a key in the _TEMPLATES dictionary whose value
> contains absolute path to the base.html.
>
> This approach seems to be more explicit but also a bit more
> complicated and still depends on the settings at the project level (on
> the other hand, having an application-level context processor seems to
> be almost inevitable). And yes, my solution seems to be somehow half-
> baked…
>
> Can this problem with the “extends” tag be solved in a more elegant
> way?
> Am I digging in a wrong direction? Is it easier to just rely on the
> Django's template scanning order and to forget the whole thing?
> What do you think?
>
> Thank you,
> -igor
>
> >
> > Looks pretty good, the only thing I would change would be to prefix
> > templates and static files with the app name, by placing them inside a
> > directory named after the app, eg 'app/templates/app/index.html', as
> > this will avoid conflicts with other templates/static media.
> >
> > Cheers
> >
> > Tom
>
> --
> 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
> (mailto:django-users@googlegroups.com).
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> (mailto: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.
Re: Directory layout for a large Django application (not project)
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]
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 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 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
>> >> ---u
Re: Directory layout for a large Django application (not project)
First of all, thanks a lot to everyone who replied :-)
Tom:
As i mentioned, i am new to Django and could be missing big parts.
Please do not hate me too much for my naivete :-)
The approach you suggested regarding the static files seems to be
reasonable. Especially considering that the static files will
eventually go to a separate server.
But I have some doubts regarding the templates. And the doubts come
exactly from that [explicit vs. implicit] perspective. Why not making
it more explicit? I mean to change it in a way that there is no need
to relay on the order in which Django searches for the templates. The
order is defined at the project level and this unnecessarily couples
my application with the project.
The only two places where the templates are referenced are the views
and other templates (in the “extends” tag). Please correct me if I am
wrong. Making it more explicit in the views is simple. E.g., it can be
done like this:
template = app_settings.path_to_template('base.html')
return render_to_response(template, …)
Here app_settings.py is a settings file that stays in the
application's root folder; and path_to_template is an application-
specific function, which returns absolute path to the template (using
os.path and the name of the app's folder).
Dealing with the templates that reference other templates (in the
“extends” tag) seems a bit trickier... One way that I found is to use
a variable in the “extends” tag. But that will require some code in
the application-specific context processor, which in turn will need to
be specified at the project level in settings.py in
TEMPLATE_CONTEXT_PROCESSORS.
In that case I can do something like this in the templates:
{% extends _TEMPLATES.base %}
where base is a key in the _TEMPLATES dictionary whose value
contains absolute path to the base.html.
This approach seems to be more explicit but also a bit more
complicated and still depends on the settings at the project level (on
the other hand, having an application-level context processor seems to
be almost inevitable). And yes, my solution seems to be somehow half-
baked…
Can this problem with the “extends” tag be solved in a more elegant
way?
Am I digging in a wrong direction? Is it easier to just rely on the
Django's template scanning order and to forget the whole thing?
What do you think?
Thank you,
-igor
>
> Looks pretty good, the only thing I would change would be to prefix
> templates and static files with the app name, by placing them inside a
> directory named after the app, eg 'app/templates/app/index.html', as
> this will avoid conflicts with other templates/static media.
>
> Cheers
>
> Tom
--
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.
Re: Directory layout for a large Django application (not project)
Interesting! So, that means you can serve blog.example.com and shop.example.com from the same server? I haven't tried any of the multi-site support in django, so not sure how this compares. Makes my head hurt to think what this does to SSL. I've never been able to figure out SSL and virtual hosting on Apache. Brian Schott bfsch...@gmail.com On Jan 10, 2012, at 6:01 AM, Cal Leeming [Simplicity Media Ltd] 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 > > -- > 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
Re: Directory layout for a large Django application (not project)
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 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
Re: Directory layout for a large Django application (not project)
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 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 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
Re: Directory layout for a large Django application (not project)
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 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.
Re: Directory layout for a large Django application (not project)
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
smime.p7s
Description: S/MIME cryptographic signature
Re: Directory layout for a large Django application (not project)
On Mon, Jan 9, 2012 at 3:11 PM, Peter Portante wrote: > Sounds like advice from the Department of the Redundancy Department. ;) I > have always wondered why Django needs to rely on the directory hierarchy for > name spacing templates. > Pros: 1) It's explicit - explicit is better than implicit 2) There is no magic - magic hides what is really happening and confuses people Cons: 1) You have to repeat yourself a bit 1) You have to repeat yourself a bit Cheers Tom -- 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.
Re: Directory layout for a large Django application (not project)
Sounds like advice from the Department of the Redundancy Department. ;) I have always wondered why Django needs to rely on the directory hierarchy for name spacing templates. On Mon, Jan 9, 2012 at 6:29 AM, Tom Evans wrote: > On Sat, Jan 7, 2012 at 7:24 PM, IgorS wrote: > > Can someone recommend “the optimal” directory layout INSIDE the > > application’s root directory for a large application. The question is > > about one application only, not the whole project. > > > > I am looking for a layout where all the code, settings, static stuff > > (images, css, js), etc. relating to this particular application stay > > inside the application’s root directory. It is probably ok to set a > > couple of values in the project's settings.py, but everything else > > should be inside the application’ directory. Something completely plug > > and play (even in a production environment)… > > > > If something “must” or should go outside of the application’s root > > (for speed optimization, etc.), that is great to know too. > > > > If, apart from the recommendations, someone could point at an existing > > large well-structured application, that would be awesome. > > > > 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 > > > > Looks pretty good, the only thing I would change would be to prefix > templates and static files with the app name, by placing them inside a > directory named after the app, eg 'app/templates/app/index.html', as > this will avoid conflicts with other templates/static media. > > Cheers > > Tom > > -- > 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.
Re: Directory layout for a large Django application (not project)
On Sat, Jan 7, 2012 at 7:24 PM, IgorS wrote: > Can someone recommend “the optimal” directory layout INSIDE the > application’s root directory for a large application. The question is > about one application only, not the whole project. > > I am looking for a layout where all the code, settings, static stuff > (images, css, js), etc. relating to this particular application stay > inside the application’s root directory. It is probably ok to set a > couple of values in the project's settings.py, but everything else > should be inside the application’ directory. Something completely plug > and play (even in a production environment)… > > If something “must” or should go outside of the application’s root > (for speed optimization, etc.), that is great to know too. > > If, apart from the recommendations, someone could point at an existing > large well-structured application, that would be awesome. > > 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 > Looks pretty good, the only thing I would change would be to prefix templates and static files with the app name, by placing them inside a directory named after the app, eg 'app/templates/app/index.html', as this will avoid conflicts with other templates/static media. Cheers Tom -- 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.
Directory layout for a large Django application (not project)
Can someone recommend “the optimal” directory layout INSIDE the application’s root directory for a large application. The question is about one application only, not the whole project. I am looking for a layout where all the code, settings, static stuff (images, css, js), etc. relating to this particular application stay inside the application’s root directory. It is probably ok to set a couple of values in the project's settings.py, but everything else should be inside the application’ directory. Something completely plug and play (even in a production environment)… If something “must” or should go outside of the application’s root (for speed optimization, etc.), that is great to know too. If, apart from the recommendations, someone could point at an existing large well-structured application, that would be awesome. 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.
