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

Hello again, Micky

As far as the structure goes, I usually have my projects laid out like
this, assuming a 'somedomain.com' parent folder that gets added to
your PYTHONPATH env variable:

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

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.

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.

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.

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.

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.

I personally believe that a canonical answer to this kind of
where-do-I-put-my-stuff question is long overdue, so I try to help as
best as I can.

Good luck and happy coding!

Sincerely,
André Terra

On 6/29/11, Micky Hulse <rgmicky@gmail.com> wrote:
> Hi Andre!
>
> Thanks so much for the reply, I really appreciate the help! :)
>
> On Wed, Jun 29, 2011 at 9:51 AM, Andre Terra <andreterra@gmail.com> wrote:
>> If you're using it for multiple apps, but just one project and the apps
>> are
>> project-specific, then this code could very well lie in your project's
>> utils.py or any other module.
>
> Doh, sorry, I should have been more clear...
>
> This code would be for one project. We do have multiple projects
> installed... I had not considered sharing between projects! :)
>
> I like your suggestion of using a utils.py file! I assume this would
> exist at the same level as the apps? For example:
>
> /my_project:
>
> __init__.py
> app1
> app2
> app3
> manage.py
> settings.py
> templates/
> urls.py
> utils.py
>
> This would be one example of code functionality that I would like to
> share between my various apps:
>
> https://gist.github.com/1027898
>
> ...
>
> Just thinking out loud here... Bear with me for a moment.
>
> Is it best to just copy code (like above) and duplicate it for each
> app, or is it better to share one piece of code between apps?
>
> Pros/cons of sharing code (like above) between apps:
>
> PRO:
>
> 1. Following DRY principle.
> 2. Faster development times (common code in one place)?
> 3. Other?
>
> CON:
>
> 1. When connected to many apps, the code becomes more risky if/when
> re-factoring is needed.
> 2. Not self-contained to application.
> 3. Things become more splintered/abstracted/other?
> 4. Other?
>
>> If you're writing code that's meant to be reused by third-parties, then
>> the
>> picture is rather different. I recently had a similar problem and I
>> thought
>> about writing a try/except block that tries to imports your global module
>> with the necessary utilities and if it fails, it defines the functions
>> itself. This way you allow for an easy global override of the needed
>> utilities in case your needs vary.
>
> Ooh, I like that idea! I think I have seen similar things in other
> programming languages myself.
>
> That's a great suggestion, thanks! :)
>
>> I'm not sure this is the standard/best practice, but I believe I've seen
>> similar bits of code in django core. A more experienced developer's point
>> of
>> view is most welcome here!
>
> That's actually a great tip... I should probably browse through the
> Django source code to find working examples. :)
>
> Thanks so much for the informative and helpful reply Andre, I greatly
> appreciate the help.
>
> Have a great day!
>
> Cheers,
> Micky
>
> --
> 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.
>
>

--
Sent from my mobile device

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