Where do you put your business logic in django? Organizing big projects in django.
MrMuffin
it into the models.py, but that file soon become huge and hard to
maintain. Of course I can just stuff it into whatever file I like, but
I`d like to have some standard way of doing this. There seems to be
something missing in django when it comes to business logic. It`s all
model, views and templates and that`s all great for small projects,
but both the models.py and views.py very soon gets huge and how do you
re-organize your project when that happens? Splitting views and models
into seperate files is only a partial solution and that requires some
hackish code in __init__.py to make syncdb etc work. And then there`s
urls.py.
Should there be a better and standardized way to organize huge
projects in django?
Thanks for your time.
Antoni Aloy
Django allows you to split your project in applications, and Django
applications are quite linked to models. But you can create your own
libraries, this is Python. As an example, we create applications to
connect to different web services and we use Django in the project.
Each web service mapping is in its own Python packages. The Django
urls and views just uses that package.
Hope it helps!
--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net
Subhranath Chunder
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Mike Dewhirst
I hope some dguru answers this because it is important.
I reckon business rules should be in models.py because that represents
the database and I've always thought that is where the business rules
belong for the sake of data integrity.
There is probably nothing wrong with multiple model files named for the
tables in the app if you want to keep them small. You might want to
import them 'from app import table_x.table_x as table_x'. Bit ugly I
suppose - this is really why it makes lotsa sense to split a big project up.
Business logic is different than business rules. That is simply the
application logic and that probably belongs in views.py but there is
nothing stopping you importing stuff from app_logic.py which can import
stuff from big_project.py.
If it is a giant project you probably ought to split it into smaller
apps each of which is focused on a self-contained subset of your entire
functionality. That way, you might be able to put parts of it on
sourceforge and I can use it :)
Mike
>
> Thanks for your time.
>
Thomas Weholt
Stuffing logic and huge amounts of code into models.py sounds like a
terrible idea. It doesn`t belong in views.py either. In a simple app
this works fine, but not for larger projects. There might be at least
two different ways to handle this; 1) like one guy points out - it`s
up to the developer to choose or 2) try to get the django
community/core dev/etc to come up with a more standard way of doing
it. I`m probably more in support of the second option.
Almost all of my projects start quite small, but outgrown one
models.py and one views.py rather quick. And that`s not even thinking
of all the business logic, just plain data models and views. So what
do I do?
Thanks for all your input anyway :-)
bruno desthuilliers
> Where do you put your business logic in django?
> In my project I`ve put
> it into the models.py,
class or function and that's not strictly tied to the HTTP request /
response cycle.
> but that file soon become huge and hard to
> maintain.
> Of course I can just stuff it into whatever file I like, but
> I`d like to have some standard way of doing this. There seems to be
> something missing in django when it comes to business logic. It`s all
> model, views and templates and that`s all great for small projects,
> but both the models.py and views.py very soon gets huge and how do you
> re-organize your project when that happens? Splitting views and models
> into seperate files is only a partial solution and that requires some
> hackish code in __init__.py to make syncdb etc work.
- it's one of - if not the main - the raison d'être of this file.
Now if your app is really growing that big, it's probably time to
refactor it into a set of related, more specialized apps. It's not as
easy as just splitting the models / views / whatever as sub-packages
of a same app, and doing so afterward will probably be more painful
than designing it right from the start, but in both cases it has the
benefit that it forces you to think about dependancies management,
which can greatly helps when it comes to maintainance.
Thomas Weholt
Ok, I see your point, but still - there`s nothing about this in the
main django documentation as far as I know. The docs should have a
section about organizing projects where the standard models.py and
views.py doesn`t fit anymore.
--
Mvh/Best regards,
Thomas Weholt
http://www.weholt.org
Benedict Verheyen
I would also like the Django guru's to come up with a best practices page.
Just ideas of how you could structure code for this or that kind of project.
You certainly can't cover all bases but at least it could serve as a starting point.
On a related note, there is a thread about the SITE_ID.
I can see how multiple sites can be managed from a single project but 1 project
means 1 settings.py file so it's not clear to me how you can then use the SITE_ID.
Anyway, as for structuring my code, I always end up splitting my models and views
and as Bruno pointed out, using __init__.py isn't hackish but takes a bit getting used too.
It's actually a nice Python feature.
Dealing with a few smaller files is in my opinion more logical, cleaner and makes
it faster to solve problems if they arise.
Putting your business logic in your models is the preferred way it seems.
If you have other code like utilities that aren't bound to http or django specific,
i would put them in a another directory, make it package and install it so
you can use it in any code/project.
I have a big project that i'm working on and i'm putting all application related code,
media and templates included, in the application directory.
To me, it makes more sense to do it like this than to have a single template directory
with sub directories for every application.
This ties the apps into the project and i want to avoid this is possible so reusing
the applications should be easier.
Regards,
Benedict
Piotr Zalewa
> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
> <bruno.des...@gmail.com> wrote:
>> Using the package's __init__.py as a facade is certainly not "hackish"
>>
>> Now if your app is really growing that big, it's probably time to
>> refactor it into a set of related, more specialized apps. It's not as
>> easy as just splitting the models / views / whatever as sub-packages
>> of a same app, and doing so afterward will probably be more painful
>> than designing it right from the start, but in both cases it has the
>> benefit that it forces you to think about dependancies management,
>> which can greatly helps when it comes to maintainance.
> Ok, I see your point, but still - there`s nothing about this in the
> main django documentation as far as I know. The docs should have a
> section about organizing projects where the standard models.py and
> views.py doesn`t fit anymore.
>
It's not there as it's a plain Python feature. Please read about it on
Python site here - http://docs.python.org/tutorial/modules.html#packages.
I've no idea if there are links to Python docs in the first djangobook
chapter or on the Django's Introduction page.
If such feature should be explained on Django docs, every other Python
feature should be there as well.
We come to this pretty often in MooTools community - it has to clearly
be said that framework is just extending the language.
Regards
Piotr Zalewa
--
blog http://piotr.zalewa.info
jobs http://webdev.zalewa.info
twit http://twitter.com/zalun
face http://facebook.com/zaloon
bruno desthuilliers
> Ok, I see your point, but still - there`s nothing about this in the
> main django documentation as far as I know. The docs should have a
> section about organizing projects where the standard models.py and
> views.py doesn`t fit anymore.
Python knowledge, and the second - refactoring into smallest apps - is
obviously encouraged by Django's philosophy, even if there are
currently some discussions about the django app as a reuseable unit.
Also, I've yet to see any framework / language / whatever
documentation mentionning any useful guideline wrt/ project's
growth !-)
Now to the point : the fact is there's no hard rule here, and it kinda
depends on your own project AND personal tastes. For some projects -
even big ones - it makes more sense to keep most of the code in the
same app and refactor modules into packages, because there's just too
much intricacy to allow for anye sane decoupling. For some other apps,
you'll easily spot a "core" part everything else depends upon and a
number of "modules" (in the generic - not Python - meaning) that
depends on the core but not on each other. You'll often find yourself
using third-parts "pluggable" apps too, so you often need an extra
"main" app taking care of the integration of your own apps and third-
part ones.
But really, this all boils down to dependancies management, and as
such is neither specific to Django nor Python.
Steve Holden
> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
> <bruno.des...@gmail.com> wrote:
>> On 27 sep, 09:08, MrMuffin <thomas.weh...@gmail.com> wrote:
>>> Where do you put your business logic in django?
>>
>> Depends on the definition of "business logic", but :
>>
>>> In my project I`ve put
>>> it into the models.py,
>>
>> That's also what I tend to do for anything that's not a pure utility
>> class or function and that's not strictly tied to the HTTP request /
>> response cycle.
>>
>>> but that file soon become huge and hard to
>>> maintain.
>>
>>
>> Then refactor your "models.py" module into a package.
>>
>>> Of course I can just stuff it into whatever file I like, but
>>> I`d like to have some standard way of doing this. There seems to be
>>> something missing in django when it comes to business logic. It`s all
>>> model, views and templates and that`s all great for small projects,
>>> but both the models.py and views.py very soon gets huge and how do you
>>> re-organize your project when that happens? Splitting views and models
>>> into seperate files is only a partial solution and that requires some
>>> hackish code in __init__.py to make syncdb etc work.
>>
>> Using the package's __init__.py as a facade is certainly not "hackish"
>>
>> Now if your app is really growing that big, it's probably time to
>> refactor it into a set of related, more specialized apps. It's not as
>> easy as just splitting the models / views / whatever as sub-packages
>> of a same app, and doing so afterward will probably be more painful
>> than designing it right from the start, but in both cases it has the
>> benefit that it forces you to think about dependancies management,
>> which can greatly helps when it comes to maintainance.
>
> Ok, I see your point, but still - there`s nothing about this in the
> main django documentation as far as I know. The docs should have a
> section about organizing projects where the standard models.py and
> views.py doesn`t fit anymore.
>
Django-specific advice.
[Thinks: definitely time for a "Python for Djangonauts" class].
regards
Steve
--
DjangoCon US 2010 September 7-9 http://djangocon.us/
Thomas Weholt
> On 9/27/2010 4:57 AM, Thomas Weholt wrote:
>> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
>> <bruno.des...@gmail.com> wrote:
>>> On 27 sep, 09:08, MrMuffin <thomas.weh...@gmail.com> wrote:
>>>> Where do you put your business logic in django?
>>>
>>> Depends on the definition of "business logic", but :
>>>
>>>> In my project I`ve put
>>>> it into the models.py,
>>>
>>> That's also what I tend to do for anything that's not a pure utility
>>> class or function and that's not strictly tied to the HTTP request /
>>> response cycle.
>>>
>>>> but that file soon become huge and hard to
>>>> maintain.
>>>
>>>
>>> Then refactor your "models.py" module into a package.
>>>
>>>> Of course I can just stuff it into whatever file I like, but
>>>> I`d like to have some standard way of doing this. There seems to be
>>>> something missing in django when it comes to business logic. It`s all
>>>> model, views and templates and that`s all great for small projects,
>>>> but both the models.py and views.py very soon gets huge and how do you
>>>> re-organize your project when that happens? Splitting views and models
>>>> into seperate files is only a partial solution and that requires some
>>>> hackish code in __init__.py to make syncdb etc work.
>>>
>>> Using the package's __init__.py as a facade is certainly not "hackish"
>>>
>>> Now if your app is really growing that big, it's probably time to
>>> refactor it into a set of related, more specialized apps. It's not as
>>> easy as just splitting the models / views / whatever as sub-packages
>>> of a same app, and doing so afterward will probably be more painful
>>> than designing it right from the start, but in both cases it has the
>>> benefit that it forces you to think about dependancies management,
>>> which can greatly helps when it comes to maintainance.
>>
>> Ok, I see your point, but still - there`s nothing about this in the
>> main django documentation as far as I know. The docs should have a
>> section about organizing projects where the standard models.py and
>> views.py doesn`t fit anymore.
>>
> I think the point is to learn enough Python that you don't need
> Django-specific advice.
>
> [Thinks: definitely time for a "Python for Djangonauts" class].
>
> regards
> Steve
>
I`m asking for a best-practice advice, and have gotten plenty of good
examples of ways to solve this "problem", but I still think this
should be covered by the standard django docs anyhow, especially since
there are some django specific magic related to the files generated by
using manage.py startapp. It`s obviously not clear to all django users
how to best handle growing projects, split into modules etc and just
taking some of the info in this thread, re-writing it and giving a few
examples and then adding it to the std docs would be enough.
bruno desthuilliers
> > I think the point is to learn enough Python that you don't need
> > Django-specific advice.
>
> > [Thinks: definitely time for a "Python for Djangonauts" class].
>
> examples of ways to solve this "problem", but I still think this
> should be covered by the standard django docs anyhow,
> especially since
> there are some django specific magic related to the files generated by
> using manage.py startapp.
> It`s obviously not clear to all django users
> how to best handle growing projects, split into modules etc
class then. FWIW, I'm amazed at how many persons seem to pick up
django without any background in Python.
> and just
> taking some of the info in this thread, re-writing it and giving a few
> examples and then adding it to the std docs would be enough.
strong emphasis on the fact that you definitly have to learn Python to
go any further would be more helpful in the long run IMHO. But well,
if you think you can contribute something useful, please go ahead and
submit your patch to the team - it's an OSS project, isn't it ?
Thomas Weholt
<bruno.des...@gmail.com> wrote:
> On 27 sep, 12:55, Thomas Weholt <thomas.weh...@gmail.com> wrote:
>> On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden <holden...@gmail.com> wrote:
>> > I think the point is to learn enough Python that you don't need
>> > Django-specific advice.
>>
>> > [Thinks: definitely time for a "Python for Djangonauts" class].
>>
>> I`m asking for a best-practice advice, and have gotten plenty of good
>> examples of ways to solve this "problem", but I still think this
>> should be covered by the standard django docs anyhow,
>
> What would you suggest exactly ?
I section under "The model layer -> Advanced" called "Organizing
models and code in larger projects". Details on how to splitting
models over several files, if and how you should seperate logic from
models etc.
>> especially since
>> there are some django specific magic related to the files generated by
>> using manage.py startapp.
>
> ??? Which "django specific magic" ???
I was referring to syncdb. As far as I know, models defined outside
any models.py or models module won`t be picked up by syncdb, but I
might be wrong.
>
>> It`s obviously not clear to all django users
>> how to best handle growing projects, split into modules etc
>
> I can only second Steve on this : time for "Python for Djangonauts"
> class then. FWIW, I'm amazed at how many persons seem to pick up
> django without any background in Python.
Hmmm ... do you or Steven know anything about my programming
background? My googling and even answers on this thread seem to
indicate that I`m not alone pondering about how to organize my django
code. I know how to structure my code in modules, but for
re-usability`s sake for instance it would be nice to have some
guidelines on how to structure your code in larger django projects and
it would be nice to have those guidelines in the otherwise excellent
django docs.
>
>> and just
>> taking some of the info in this thread, re-writing it and giving a few
>> examples and then adding it to the std docs would be enough.
>
> Mmm... Not sure this would help. A pointer to Python's doc and a
> strong emphasis on the fact that you definitly have to learn Python to
> go any further would be more helpful in the long run IMHO. But well,
> if you think you can contribute something useful, please go ahead and
> submit your patch to the team - it's an OSS project, isn't it ?
I`m trying to contribute to the django community by writing code,
reusable apps, being active on gropus like this etc. I could even try
to help out writing docs, but if my questions are going to be answered
by people who question my competence that wouldn`t be very motivating,
would it?
I`ll take all the hints and advice given in this thread and try to use
it to organize my ongoing project.Thanks for your time, everyone.
Regards,
Thomas
werefr0g
The following is quite long but reflects a non developper point of view. I'll expose briefly that business analysis already splits logic and why I think you should follow previous recommandations. I'll finish "out of subject" commenting your documentation request.
> Split business logic
When you have to describe business logic to a dev, seperating business responsabilities is a good start. I think it's a thought orientation shared by "business analysts" (I'm not sure this is the right term in english) and developpers. The process often shows that a same object can be approached from different perspectives (for exemple, sales, comptability, logictic both work with orders but with different perspectives). You'd better keep this object as generic as possible and let each perspective set its own attributes at its very level. This mailing list shows multiple practical examples with the User notion.
In the process, you have to be consistent and a direct extra benefit is polishing each application interface. From a non developper point of view, I find far most easier to write applications when the semantic and the interfaces are clean. It helps your application's usability and it's documentation too.
As most developpers complain, business logic tends to change and it's implementation has to follow. Both at business and application levels, these changes should be kept at their perpective level (for example, a change in accounting should not compromise other fields and not be a revolution in actual business if possible).
My point is that it is a normal business analysis process to split responsabilities as far as possible and Django allows you to write multiple apps to implement that. Implementation problems are about the same that those brought while debatting applications reusability. If your project may have multiple dependencies, your app should keep them minimal at their level: this process is already part of business analysis when modeling "packages".
In business, a task can be reassigned: if you want something done, you must ask somewhere else. Putting that in Django, if you want to reach a ressource, you use an url and the url mapper will call the ressource for you. Django allows you to name your urls and you can implement get_absolute_url easily. I see the way Django handles urls as a great strength. I take the opportunity to state that url are part of a web application interface (browsers are only a part of available clients).
To rephrase all of that, splitting your project in multiple parts is already a business analysis requierement before reaching the developpement process.
> Documentation and guidelines
When speaking about Django's pro, the admin and the documentation come often. They reflect both a practical approach. Django's documentation show it's developpers philosophy and puts emphasis on good practices. Django's original design history and the framework's multiple actual fields of application tend to proove that team's member are not totally subject to delusion ;).
I found that adding guidelines on a subject to applications' documentation helps greatly: it summarise the concepts, reinforce consistency and puts the recent knowledge on another perspective, acting as a seal. It draws practical schemas and are good entry points to the "practical cases to concepts" learners and can bring "step by step" learners to a more self-implying approach. It reinforce pattern recognition during the analysis. They are often used for feedback. Writing them is time consumming, that's the bad part.
Ensuring that applications are designed to properly integrate into the framework helps to reinforce the framework. Extensions / plugins / adapters are considered when chosing a solution and for Django, they are the apps. Django is a practical solution by its extension ability. A pro often advanced in favor of frameworks usage is the standardisation of the developpement process.
Explicitly tell the direction is the most simple way to garanty that, as far I can tell.
While speaking of designing applications, I think that testing should be shown since the tutorial, at least in a minimal form. (by the way, testing advocates again a rationnal spread of responsabilities into the project).
> Thanks
Sorry, I lied in the begining. I was quite long so if you reach this point, you'll don't mind if I thank both Django's team to brought me into the enjoyment of developpement and the community for its participation and its enthousiasm.
Regards,
Steve Holden
> On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
> <bruno.des...@gmail.com> wrote:
>> On 27 sep, 12:55, Thomas Weholt <thomas.weh...@gmail.com> wrote:
>>> On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden <holden...@gmail.com> wrote:
>>>> I think the point is to learn enough Python that you don't need
>>>> Django-specific advice.
>>>
>>>> [Thinks: definitely time for a "Python for Djangonauts" class].
>>>
>>> I`m asking for a best-practice advice, and have gotten plenty of good
>>> examples of ways to solve this "problem", but I still think this
>>> should be covered by the standard django docs anyhow,
>>
>> What would you suggest exactly ?
>
> I section under "The model layer -> Advanced" called "Organizing
> models and code in larger projects". Details on how to splitting
> models over several files, if and how you should seperate logic from
> models etc.
>
>>> especially since
>>> there are some django specific magic related to the files generated by
>>> using manage.py startapp.
>>
>> ??? Which "django specific magic" ???
>
> I was referring to syncdb. As far as I know, models defined outside
> any models.py or models module won`t be picked up by syncdb, but I
> might be wrong.
>
up could well be useful.
>>
>>> It`s obviously not clear to all django users
>>> how to best handle growing projects, split into modules etc
>>
>> I can only second Steve on this : time for "Python for Djangonauts"
>> class then. FWIW, I'm amazed at how many persons seem to pick up
>> django without any background in Python.
>
> Hmmm ... do you or Steven know anything about my programming
> background? My googling and even answers on this thread seem to
> indicate that I`m not alone pondering about how to organize my django
> code. I know how to structure my code in modules, but for
> re-usability`s sake for instance it would be nice to have some
> guidelines on how to structure your code in larger django projects and
> it would be nice to have those guidelines in the otherwise excellent
> django docs.
>
Hold hard, there! That's Steve, not Steven, Thomas. And I was musing
about it being an opportunity to write and promote a new training class,
rather than specifically suggesting that you personally needed training.
>>
>>> and just
>>> taking some of the info in this thread, re-writing it and giving a few
>>> examples and then adding it to the std docs would be enough.
>>
>> Mmm... Not sure this would help. A pointer to Python's doc and a
>> strong emphasis on the fact that you definitly have to learn Python to
>> go any further would be more helpful in the long run IMHO. But well,
>> if you think you can contribute something useful, please go ahead and
>> submit your patch to the team - it's an OSS project, isn't it ?
>
> I`m trying to contribute to the django community by writing code,
> reusable apps, being active on gropus like this etc. I could even try
> to help out writing docs, but if my questions are going to be answered
> by people who question my competence that wouldn`t be very motivating,
> would it?
>
I don't think anyone's questioning your competence, and your desire to
help in a community-spirited way is very welcome. But you should realize
(and probably will if you think about it) that many people who do ask
questions on this list could use better Python knowledge than they
currently have. If you aren't in that position then fine.
> I`ll take all the hints and advice given in this thread and try to use
> it to organize my ongoing project. Thanks for your time, everyone.
>
You are correct in saying that the Django docs are excellent, but
there's only so much they can do.
If you do come up with useful guidelines I am sure that nobody is going
to complain if you submit a patch to the docs. One of the issues is that
size is not the only metric of complexity, and it's difficult to frame
generic advice about the organization of large projects.
bruno desthuilliers
On 27 sep, 17:31, Thomas Weholt <thomas.weh...@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
>
>
> I was referring to syncdb. As far as I know, models defined outside
> any models.py or models module won`t be picked up by syncdb, but I
> might be wrong.
but there's no "magic" involved here - just a naming convention - and
startapp has nothing to do with it.
> >> It`s obviously not clear to all django users
> >> how to best handle growing projects, split into modules etc
>
> > I can only second Steve on this : time for "Python for Djangonauts"
> > class then. FWIW, I'm amazed at how many persons seem to pick up
> > django without any background in Python.
>
> Hmmm ... do you or Steven know anything about my programming
> background?
remark was not specifically about you, and was not intended as
criticism FWIW, quite on the contrary. Now I don't think there's that
much Django-specific knowldege involved when it comes to managing a
growing code base, and Django's manual is about Django, not about
Python.
(snip the remaining - Steve already answered better than I could do)
Diederik van der Boor
> Where do you put your business logic in django? In my project I`ve put
> it into the models.py, but that file soon become huge and hard to
> maintain. Of course I can just stuff it into whatever file I like, but
> I`d like to have some standard way of doing this. There seems to be
> something missing in django when it comes to business logic. It`s all
> model, views and templates and that`s all great for small projects,
> but both the models.py and views.py very soon gets huge and how do you
> re-organize your project when that happens? Splitting views and models
> into seperate files is only a partial solution and that requires some
> hackish code in __init__.py to make syncdb etc work. And then there`s
> urls.py.
I'm surprised no one mentioned manager classes yet. This is an example for
models.py:
from django.db import models
from yourapp.managers import SomeObjectManager
class SomeObject(models.Model):
objects = SomeObjectManager()
Now you can do things like: SomeObject.objects.foo() which is defined in your
manager class. This allows a much better separation of logic and models.
> Should there be a better and standardized way to organize huge
> projects in django?
Yes. Making multiple applications. I highly recommend watching this DjangoCon
video by James Bennett: http://www.youtube.com/watch?v=A-S0tqpPga4
It explains how apps can be made reusable. For example a "blog" application is
actually not 1 monolythic application, but 8+ tiny apps. User registration and
account management can also be written as 4+ little apps.
SInce watching that video, my projects are composed by default of 2 apps. A
"projectname" for the core backend stuff, and a "projectname-site" with the
templates, settings, and frontend media. This is imho a nicer base to start
"hooking in" more applications.
More functionality (tagging, rating, accounts, etc.. will all become separate
apps) which will be hooked in the "projectname-site" project. In case you
wonder, http://www.djangopackages.com/ gives you quite a wealth of small
reusable parts that can be hooked in directly.
Greetings,
Diederik
Benedict Verheyen
<snip>
> SInce watching that video, my projects are composed by default of 2 apps. A
> "projectname" for the core backend stuff, and a "projectname-site" with the
> templates, settings, and frontend media. This is imho a nicer base to start
> "hooking in" more applications.
Can you give an example of the second application where you put the templates,
settings and so on?
I'm trying to put all the media, templates in the application directory.
However, it's not clear to me how i can do this as you end up with 2 media url's.
One for the project and one for the applications, same goes for the templates.
Regards,
Benedict
Benedict Verheyen
I agree with Thomas that at least some guidelines would be nice.
As what you and Steve have been saying about the need for a "Python for Djangonauts" class,
i think it would be a good idea also.
I'm wondering though what specific Python topics you would touch?
One that comes to mind is the use __init__,py and this modules in general as this
knowledge is needed to understand how you can split your models and views.
This would be what i would put in the guidelines for code structuring.
Topics i think would be interesting:
1. Project vs App
- What is a project? When do you use applications?
- Possible examples of coding structure
- 1 site in 1 project
- many sites in 1 project
- ...
2. Splitting models & views
3. How can you cleanly seperate an application further from a project
4. Building reusable applications
5. Advanced building methods
- Buildout
- Virtualenv
- ...
If we could agree on a list of topics, we can start writing it ourselves.
We have people here with lots of experience regarding these kind of
more advanced topics.
I wouldn't mind to write something on point 2 but that would need
to be verified by someone with loads more experience than me before
it could be published.
Regards,
Benedict
bruno desthuilliers
wrote:
> As what you and Steve have been saying about the need for a "Python for Djangonauts" class,
> i think it would be a good idea also.
> I'm wondering though what specific Python topics you would touch?
this point it's more about learning Python than anything else.
But the most obvious points are probably about Python's execution
model:
* what happens when a .py file is loaded into the interpreter, whether
thru direct execution ('> python somefile.py') or via an import,
* modules, packages, and the pythonpath
* import hooks and how django use them
> One that comes to mind is the use __init__,py and this modules in general as this
> knowledge is needed to understand how you can split your models and views.
> This would be what i would put in the guidelines for code structuring.
> Topics i think would be interesting:
> 1. Project vs App
> - What is a project? When do you use applications?
> - Possible examples of coding structure
> - 1 site in 1 project
> - many sites in 1 project
> - ...
on these points might be a good thing.
> 2. Splitting models & views
package without breaking client code.
> 3. How can you cleanly seperate an application further from a project
there are indeed quite a few Django-specific points here.
> 4. Building reusable applications
There are already some threads, blog posts etc on this, but I've met a
couple issues never adressed so far.
bobhaugen
and best practices for modularizing large projects.
For example, http://groups.google.com/group/django-users/browse_thread/thread/22875fd287d0aa81
I expect the situation to improve, or at least change, a lot over the
next year.
In general, this is mostly about refactoring, so maybe this is a good
reference, although it tends to be java-oriented:
http://www.refactoring.com/
Thomas Weholt
that mainly consists of a couple of management commands, like
startbigapp ( working name ) which is a crude hack of the startapp
code in django. It creates module for models and views instead of the
standard views.py and models.py. Another command is addmodel
<app_name> <model1> <model2> which will support the module layout
created by startbigapp, but will also create scaffolding using generic
views and basic templates for new/update/list/delete of the specified
models ( the models doesn`t have fields, that will have to be added
manually ). It saves some time and reducing repetetive typing. I was
thinking of making a command that would take an existing app and
generate a new version of the app splitting models ( and perhaps views
? ) into modules. The app will be a collection of helper methods for
code organizing and generation of boilerplate code. Any thoughts or
ideas?
I`ll upload it to the cheeseshop as soon as I can get time to
debug/test a bit more. The code isn`t pretty at the moment, but it
seems to get the job done.
SivaTumma
Please address with @ symbol and name if you are actually intending
someone to read,
and then please delete the already existing message in your reply.
That makes us poor people to read things clearly and make up something
out of important discussions like these.
bruno desthuilliers
> Inspired by the discussions in this thread I've created a reusable app
> that mainly consists of a couple of management commands, like
> startbigapp ( working name ) which is a crude hack of the startapp
> code in django. It creates module for models and views instead of the
> standard views.py and models.py.
What your command creates are packages (folders with an __init__.py
module).