Re: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 28 sep, 17:32, Thomas Weholt  wrote:
> 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.

Just for the record: "views.py" and "models.py" are actually modules.
What your command creates are packages (folders with an __init__.py
module).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[SivaTumma]

A small feature suggestion for @All,

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.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Thomas Weholt]

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. Another command is addmodel
   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.

-- 
Mvh/Best regards,
Thomas Weholt
http://www.weholt.org

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bobhaugen]

Seems to be a general ferment on the topics of reusable Django apps
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/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 28 sep, 10:02, Benedict Verheyen 
wrote:
> 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?

I'd be tempted to answer : all of Python - hence my opinion that at
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 is already explained in Python's fine manual.

> 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
>         - ...

Ok, this is more Django-specific, and I agree that sharing experience
on these points might be a good thing.

> 2. Splitting models & views

It's a more general pattern: turning a module (single .py file) into a
package without breaking client code.

> 3. How can you cleanly seperate an application further from a project

Part of this topic is mostly generic dependencies management, but
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.

> 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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Benedict Verheyen]

On 28/09/2010 0:48, bruno desthuilliers wrote:
> 
> 
> On 27 sep, 17:31, Thomas Weholt  wrote:
>> On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
>>
> 
>>> ??? 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.
> 
> s/module/package/ !-)
> 
> 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?
> 
> Nope, and neither Steve nor I did question your competence. The above
> 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)
> 

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


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Benedict Verheyen]

On 27/09/2010 23:59, Diederik van der Boor wrote:


> 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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Diederik van der Boor]

Op maandag 27 september 2010 09:08:53 schreef MrMuffin:
> 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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 27 sep, 17:31, Thomas Weholt  wrote:
> On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
>

>> ??? 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.

s/module/package/ !-)

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?

Nope, and neither Steve nor I did question your competence. The above
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)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Steve Holden]

On 9/27/2010 11:31 AM, Thomas Weholt wrote:
> On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
>  wrote:
>> On 27 sep, 12:55, Thomas Weholt  wrote:
>>> On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden  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.
> 
An addition to the documentation about why your models may not be picked
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.

regards
 Steve
-- 
DjangoCon US 2010 September 7-9 http://djangocon.us/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[werefr0g]

 Hello,

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,

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Thomas Weholt]

On Mon, Sep 27, 2010 at 4:52 PM, bruno desthuilliers
 wrote:
> On 27 sep, 12:55, Thomas Weholt  wrote:
>> On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden  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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 27 sep, 12:55, Thomas Weholt  wrote:
> On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden  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 ?

> especially since
> there are some django specific magic related to the files generated by
> using manage.py startapp.

??? Which "django specific magic" ???

> 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.

> 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 ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Thomas Weholt]

On Mon, Sep 27, 2010 at 12:40 PM, Steve Holden  wrote:
> On 9/27/2010 4:57 AM, Thomas Weholt wrote:
>> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
>>  wrote:
>>> On 27 sep, 09:08, MrMuffin  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"
>>> - 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.
>>
>> 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.

-- 
Mvh/Best regards,
Thomas Weholt
http://www.weholt.org

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Steve Holden]

On 9/27/2010 4:57 AM, Thomas Weholt wrote:
> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
>  wrote:
>> On 27 sep, 09:08, MrMuffin  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"
>> - 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.
> 
> 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

-- 
DjangoCon US 2010 September 7-9 http://djangocon.us/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 27 sep, 10:57, Thomas Weholt  wrote:
> 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.

FWIW, the first solution - refactoring modules into apps - is common
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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Piotr Zalewa]

 On 09/27/10 09:57, Thomas Weholt wrote:
> On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
>  wrote:
>> Using the package's __init__.py as a facade is certainly not "hackish"
>> - 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.
> 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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Benedict Verheyen]

On 27/09/2010 9:08, MrMuffin wrote:
> 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.
> 
> Should there be a better and standardized way to organize huge
> projects in django?
> 
> Thanks for your time.
> 

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




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Thomas Weholt]

On Mon, Sep 27, 2010 at 10:38 AM, bruno desthuilliers
 wrote:
> On 27 sep, 09:08, MrMuffin  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"
> - 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.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[bruno desthuilliers]

On 27 sep, 09:08, MrMuffin  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"
- 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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Thomas Weholt]

On Mon, Sep 27, 2010 at 10:07 AM, Mike Dewhirst  wrote:
> On 27/09/2010 5:08pm, MrMuffin wrote:
>>
>> 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.
>>
>> Should there be a better and standardized way to organize huge
>> projects in django?
>
> 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.

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 :-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Mike Dewhirst]

On 27/09/2010 5:08pm, MrMuffin wrote:

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.

Should there be a better and standardized way to organize huge
projects in django?


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.



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Subhranath Chunder]

Sometimes I put it in some 'utils.py' in the app directory, and sometimes in
'views.py' itself, with leading underscores, whichever I feel is more
appropriate.

I guess this would be more of the developer's choice. Any better
suggestions?

Thanks,
Subhranath Chunder.

On Mon, Sep 27, 2010 at 12:43 PM, Antoni Aloy  wrote:

> 2010/9/27 MrMuffin :
> > 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.
> >
> > Should there be a better and standardized way to organize huge
> > projects in django?
> >
> > Thanks for your time.
> >
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@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-us...@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: Where do you put your business logic in django? Organizing big projects in django.

[Antoni Aloy]

2010/9/27 MrMuffin :
> 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.
>
> Should there be a better and standardized way to organize huge
> projects in django?
>
> Thanks for your time.
>

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.