I tend to split mine up based upon URLs. For example, all User-Authentication stuff I may put into a 'user' app. All misc. things that don't seem to have a proper place might go into a 'core' app. Some times this is especially helpful as you can just include an entire App in your main urls.py and worry about maintaining that "module" of code almost completely separately. To really build a "modular", re-usable application, you'll have to design it that way. It can be tough, and sometimes impossible, but it has it's advantages.
On Wed, Oct 12, 2011 at 1:04 PM, Javier Guerra Giraldez <jav...@guerrag.com>wrote: > On Wed, Oct 12, 2011 at 11:14 AM, Guillaume DE BURE > <guillaume.deb...@gmail.com> wrote: > > Being still quite new to django, I have some very basic questions on > this: > > * Should each module be a django app ? Or is it something > different ? > > * Is there already something existing (a third party app ?) to provide > this > > kind of mechanism ? > > * If not, does anyone has experience implementing such behaviour ? > > i struggled with the same for some time. the 'app' name seems to > imply that it's a section of the website, or even a full application. > but in fact it's more about internal functionality. > > my process is roughly like this: > > - create the project and add a few basic apps: south, > django-extensions, debug-toolbar, so on. > > - create an app and open the models.py > > - on a terminal, i start a simple shell that runs the graph_models > command of django-extensions, generating a nice relationship diagram > that i keep open on a different window. the diagram is rebuild each > time a models.py is modified. > > - i start writing models, watching the diagram evolve. i think of > normalization rules, and at the same time imagine user cases and what > kind of data requests i'll need to fulfill the user needs. > > - after a while, patterns start to emerge, small clusters of models > are loosely bound to other clusters. then i try to see the direction > of the arrows, as soon as i see a cluster points to another without > any relationship in the other direction, i interpret as a sign that it > should be a new app. the important part is the direction of the > arrows, that means one app depends on the other, but not the other > way. of course, it's better when you can make an app depend only on > Django core; but usually you'll find that some apps are > 'infrastructure' and others are more 'high level' > > - i keep splitting, and sometimes rejoining apps until most of the use > cases are either obvious from the diagram, or at least have complexity > bounded on a single app. > > - then i start adding methods to the models (tests first!... or at > least i should. creating sample data is the tedious part). i try to > have tests that represent most use cases in the data manipulation part > (still no views). sometimes that implies creating a whole API. > > - then, and only then, i start creating views. most of them will be > concerned with a single 'high level' app and maybe some readonly > access to other apps, but there are cases where a view touches > functionality from several apps. in that case, i create a new > model-less app, just to hold those views. > > > hope that helps > > > -- > Javier > > -- > 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.
