Hmm. Some of my posts are duplicated two days after the fact. It looks like
gmane plays tricks after being down for some time. I apologize for that.
"Eugene Lazutkin" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
>
> I want to throw in an idea related to apps. Hugo, Sune, and I h
I want to throw in an idea related to apps. Hugo, Sune, and I had a
discussion some time ago about get_absolute_url() in models. My idea is
totally half-baked, undetailed, and flawed. I want to collect some input and
your ideas.
Basically I was thinking about settings.py-style file for apps. I
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>
>Thoughts?
+1
Robert Wittams wrote:
> Are you using the app template loader? templates go in /templates .
> Seems eminently sensible to me.
> The project wide stuff is useful for overriding app provided templates.
No, I'm not. Clearly I need to do some reading :-)
Bill de hÓra wrote:
* Change django-admin.py so that the various commands that act on apps
-- such as sql, install and sqlreset -- take the *full app name* (e.g.
"myproject.polls") instead of the name of the Python module that holds
the models. This would have the following subtle side effect:
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>
>Thoughts?
+1.
I want to throw in an idea related to apps. Hugo, Sune, and I had a
discussion some time ago about get_absolute_url() in models. My idea is
totally half-baked, undetailed, and flawed. I want to colle
Tim Keating wrote:
> +1 for me; if you start thinking about doing the same with views, have
> a preemptive +1 for that, as well :-)
>
> Then maybe we can start talking about how wrong it is where templates
> live right now . . .
>
> TK
>
>
Are you using the app template loader? templates go
Adrian Holovaty wrote:
> * Change "django-admin.py startapp" so that it creates a models.py
> file instead of a models package with __init__.py and appname.py in
> it.
+1
> * Change django-admin.py so that the various commands that act on apps
> -- such as sql, install and sqlreset -- take th
+1 for me; if you start thinking about doing the same with views, have
a preemptive +1 for that, as well :-)
Then maybe we can start talking about how wrong it is where templates
live right now . . .
TK
>What's the best way to deal with this sort of change in the docs, now
>that we have a release?
Easy: put the 0.90 docs in their own folder, let the "Documentation"
point to the trunk documentation, but put a "release documentation"
link at the top (or the other way around, make the release
docum
On 11/18/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> What's the best way to deal with this sort of change in the docs, now
> that we have a release?
How about doing like python.org does with documentation?
Having a subdirectory for trunk and for each release under
documentation would be a go
On 11/18/05, hugo <[EMAIL PROTECTED]> wrote:
> After having to discuss the polls (app_label) vs. polls (model module)
> vs. polls (the different files) today at work, I am all +1 for that one
OK, judging by people's immediate responses, it looks like I'll be
making the change.
A related question
# But the logic being discussed is the same that Python uses when
# doing imports, so it seems to me to be The Right Way from a language
# POV, no?
Hm. Yeah. Supporting a models module would be good for folks who
would like to break their models into different modules, whereas a
single models.p
On 11/18/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts?
I'm all for this change; it would make my tab-completion work sooo much
better :)
Also, why not scrap package-support entirely, anyone wanting the
models spread over several files can just
from foo import *
from bar import
On 11/18/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
# * Change Django so that it looks for models in a "models" package# (as it currently does) *or* in a file called models.py. Either the# models package or models.py should live directly within the package
# pointed-to by INSTALLED_APPS.Do y
>The main advantage of the models.py solution is it's less >complexity
>(fewer files to juggle), and the file is called models.py instead of
>(in the tutorial's example) polls.py. The fewer files named >polls.py, the
>better.
After having to discuss the polls (app_label) vs. polls (model module)
# * Change Django so that it looks for models in a "models" package
# (as it currently does) *or* in a file called models.py. Either the
# models package or models.py should live directly within the package
# pointed-to by INSTALLED_APPS.
Do you think the extra option will confuse anyone when the
Overall, anything that doesn't require packages but that accomodates both modules or packages depending on the complexity of the system, and defaults to modules, strikes me as pythonic.I'm pretty new to Django's "app" concept, though, and it seems you're slightly messing with it here, so I'll +0 on
On Nov 18, 2005, at 1:55 PM, Adrian Holovaty wrote:
Thoughts?
+1 -- great call.
Jacob
I'm on a quest to simplify Django's default project layout even more.
Right now, "django-admin.py startapp" creates a "models" directory
within the app directory -- and, in fact, it's required by Django that
models live in a "models" directory within a package pointed-to by
INSTALLED_APPS.
Here's
20 matches
Mail list logo
