On 11/18/05, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> On 18 Nov 2005, at 18:26, David Ascher wrote:
>
> > It's very possible that the use case it supports (repeatedly
> > switching b/w projects when invoking django-admin.py) isn't
> > frequent enough to warrant the increased complexity.
>
> I
On 11/18/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
I don't care how many layers we are going to have in
implementation, I care for the final layer --- actual use of Ajax in templates.
RPC is not a final layer for me, because I suspect that majority of user will
need end user function
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:
Let me present my half-cooked view of the layers.
I don't care how many layers we are going to have in
implementation, I care for the final layer --- actual use of Ajax in templates.
RPC is not a final layer for me, because I suspect that majority of user will
need end user functionality,
There is a well know effect related to the light speed limit. :-) Basically
it adds some constant delay to all packets. This delay depends on physical
wire distance between client and server. Even if you have infinite
bandwidth, you will still experience delay. Retransmissions of packets and
techn
"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
WFIW, Dojo collects CLAs from contributors. I signed it, when
submitted code.
OTOH, anybody can be sued for no reasons whatsoever. Don't ask
me how I know it. :(
Thanks,
Eugene
"David Ascher" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]...IP
discussions are wort
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
On 18 Nov 2005, at 19:08, hugo wrote:
Please not AJAX-only - we do still want to validate on POST, too, as
the user might just have JavaScript disabled or is using IE with
settings that don't allow the XmlHttpRequest object ...
That should go without saying - server-side validation will alwa
+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
Regarding the original issue (putting the project directory into the
PYTHONPATH), is the implication that django-admin would automagically
append the directory where it locates the settings.py file to sys.path?
Or is this not intended to address that concern at all?
BTW Simon, beware; "knock up"
>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
>If I get some spare time soon I think I'll build the Ajax-only
>validation thing as a proof of concept. I'm willing to bet that the
>performance difference between it and pure client-side validation
>will be imperceptible in most cases. If it's noticable and obvious
>that the user experience woul
On 18 Nov 2005, at 19:37, Simon Willison wrote:
On 18 Nov 2005, at 18:26, David Ascher wrote:
It's very possible that the use case it supports (repeatedly
switching b/w projects when invoking django-admin.py) isn't
frequent enough to warrant the increased complexity.
It's frequent enough t
On 18 Nov 2005, at 18:26, David Ascher wrote:
It's very possible that the use case it supports (repeatedly
switching b/w projects when invoking django-admin.py) isn't
frequent enough to warrant the increased complexity.
It's frequent enough to drive me potty. I think I'll try to knock up
On 11/18/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
I guess all this just rubs me the wrong way, because it breaksthe Only One Way guideline.And it should thus be challenged, no argument here.It's very possible that the use case it supports (repeatedly switching b/w projects when invoking
django-
On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
> So I don't think it would break under apache -- Apache would still require
> the same environment variable to be set. But maybe I'm missing something?
My point exactly :) Also, if a users places a settings-file outside her
PYTHON_PATH, it wi
On 11/18/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Oooh, this is a nice idea! Is anybody willing to submit a patch?
An idea: It could be a new settings module d.s.like_perforce,
which finds the settings-file like described, evals it and reexports
the settings it contains. That way everythi
On 11/18/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
I suggest this, because I think it's a rather poor idea; my biggestproblem with it is that it will break under Apache. So suddenlydjango-admin and the handlers do different things, which isbound to cause surprises...
That's exactly the kind of f
On 11/18/05, David Ascher <[EMAIL PROTECTED]> wrote:
> I guess I wasn't clear. What p4 does (and I propose django-admin does) is
> look for an environment variable called DJANGO_SETTINGS_NAME, and use "
> settings.py" if it doesn't find such an environment variable. It then looks
> for a file wi
On 18 Nov 2005, at 15:49, Robert Wittams wrote:
I think that sounds pretty good.
+1 - sounds excellent to me.
On 17 Nov 2005, at 23:04, Christopher Lenz wrote:
I don't agree, at least for the common cases such as validating
emails, URLs, date/time fields etc. It really shouldn't be
necessary to call back to the server for trivial and/or common
validation tasks.
I don't understand why not. It's
David Ascher wrote:
> On 11/17/05, Tim Keating <[EMAIL PROTECTED]> wrote:
>
>>
>>It's an interesting idea . . . I know why perforce works this way, but
>>I'm curious what problem this addresses. Most of the stuff that lives
>>in the P4CONFIG file is located in /settings.py, as far as I
>>can tell
On 11/18/05, Tim Keating <[EMAIL PROTECTED]> wrote:
> It seems like we could handle this situation better, but I'm hanged if I
> know what the Right Thing to Do is. Give a more meaningful error
> message? (Is it necessarily an error to have a date value of 0?)
> Convert to NULL? Something else?
>
Here are my half cooked thought on the issue.On 11/18/05, Wilson Miner <[EMAIL PROTECTED]
> wrote:
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,and all Django code builds on the delivered ones. But we don't enforcethose on
As David already mentioned, obtaining the copyright now is easier than later.
the reason you want this is so If you have to change your license in
years to come (which the ASF had gone through recently) you can easily
do this.
Another reason I have seen is when a individual contributor is doing
t
On 11/17/05, Tim Keating <[EMAIL PROTECTED]> wrote:
It's an interesting idea . . . I know why perforce works this way, butI'm curious what problem this addresses. Most of the stuff that livesin the P4CONFIG file is located in /settings.py, as far as I
can tell. And I'm not clear how this would solv
38 matches
Mail list logo
