Re: Global generic files? Best practice(s)?

Hello Andre! Thanks so much for your help, I really appreciate the pro
advice!!! :)

On Thu, Jun 30, 2011 at 6:01 AM, Andre Terra <andreterra@gmail.com> wrote:
> __init__.py
> app1/
> app2/
> appN/
>    __init__.py
>    models.py
>    views.py
>    urls.py
>    forms.py
>    templates/
>    utils.py
> project/
>    __init__.py
>    forms.py
>    settings.py
>    urls.py
>    utils.py
>    views.py
>    templates/
>    static/
>    (etc.)

Oooh, I really like the above setup!

That's similar to how I setup my very first Django project/app (sorry,
poorly packaged... er, not packaged at all!):

https://github.com/mhulse/code.hulse.me/tree/master/webapps

project/
__init__.py
manage.py
settings.py
urls.py
views.py
apps/
app1/
app2/
templates/
app1/
app2/

That layout seemed to work well for that particular project.

At work, we use a more out-of-the-box setup:

project/
__init__.py
manage.py
settings.py
urls.py
views.py
app1/
__init__.py
views.py
models.py
admin.py
helpers.py
managers.py
validators.py
widgets/
urls.py
forms.py
fields.py
utils.py
templates/
app1/
app2/
app3/
templates/
app1/
app2/
app2/

I really like your suggested setup though! Putting the apps at the
same level as the project seem to make a lot of sense.

Using the project as a container for utils.py is a great idea also. :)

> Which basically means my project is just another app. Nothing is
> preventing you from creating utils.py files in your apps, or even
> settings.py that get loaded from an import in your project's settings.

Yes! That sounds like an optimal setup! :)

When you talk about an app's settings.py file, do you just put
something like this:

from app import settings

... at the top of the project's settings.py file?

I had never considered doing that before... I will have to experiment.
Thanks for tip!

> I find this arrangement to be the best for my development workflow
> after many other attempts. This also helps newcomers avoid the often
> made mistake of referencing their apps in relation to the project like
> from project.app1 import views
> which would prevent the code from being reused in other projects.

Hehe, I can relate. Been there, done that. :)

> About your Place model, my recommendation/guess would be to abstract
> it one more time so that you could have a global BasePlace class which
> gets subclassed in an app-specific Place model.

That's an interesting idea!

I actually have several (abstract) models similar to "Place" that I
could use in my various apps/projects... I have found myself
duplicating the code for these various apps... It would be great to
put them at a higher level and import/sub-class as they are needed.

> Or at least that's what I thought last nignt before going to sleep. As
> I write this, I realize that a BasePlace would have no place (pun not
> intended) in your project, so maybe what you need is a package for
> your multiple apps which in turn gets imported into your project.

That's a great idea/tip!

You inspired me to create my first pip-installable package:

https://github.com/mhulse/django-goodies

Not much there at the moment, but I plan on adding more code at a later date.

The instructions found below were very helpful:

http://guide.python-distribute.org/creation.html

On my testing server, I was able to pip install django-goodies without
a hitch (I have yet to actually import and utilize the Place model in
a project/app though... It's getting late.) :(

> I'm pretty much guessing at this point, but in doing so, I have
> hopefully given you food for thought while also bumping the thread so
> that other developers will weigh in.

Definitely! Thanks so much!!!! I really appreciate it! :)

Have a great day.

Cheers,
Micky

--
Micky Hulse
Web Content Editor
The Register-Guard
3500 Chad Drive
Eugene, OR 97408
Phone: (541) 338-2621
Fax: (541) 683-7631
Web: <http://www.registerguard.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-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.