Bjørn Stabell wrote:
> I do remember posting a comment on the Django docs site about
> mod_python and mpm-worker crashes a while ago, but I cannot find it on
> the Django site anymore.
>
> In any case, we were using mod_python 3.1.3-3. I'm happy to hear it's
> been fixed in 3.2.8. Unfortunately
There has been lots of talk about extending the User object with the
AUTH_PROFILE_MODULE setting. That, along with a multi-site app I am
working on has lead me to wonder, What about extending the Site object
with a SITE_PROFILE_MODEL setting.
I guess you could accomplish the same thing with cust
On 8/24/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>
> I gather this proposal means validation will be highly optimised for web
> forms and available only on POST? I understand that is the mainline use
> case, but I have a preference something that wasn't baked into HTML 'cos
> I'll have to hack
James Bennett wrote:
> On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
>> plan in Trac?
>
> I think Brant's rocking the sexiness; the concept of validation
> behaving as a try/except block feels nice to me. And bidding
On Aug 24, 2006, at 2:14 PM, mediumgrade wrote:
> Don't know if this is a Django question or not, but here is the
> situation:
>
> I am developing an application for a client who is a automobile
> broker.
> He wants agents to submit requests for vehicles from the web. The
> agent
> will be abl
On 8/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Al-rightly then... thoughts?
>
+1 ValidationErrors with an s, as I've said before: the more errors
returned at once, the better.
My problem with Joseph's proposal is that I believe it to be too tied
to the concept of the Model. Idealy
Don't know if this is a Django question or not, but here is the
situation:
I am developing an application for a client who is a automobile broker.
He wants agents to submit requests for vehicles from the web. The agent
will be able to select the make/model of the vehicle. What I want is
for the m
JP wrote:
> Also, exceptions are very
> expensive,
while this is true in java or c++, it is not necessarily true in python.
even python itself uses exceptions for example when doing a for-loop
over an iterable (the iterator's next() method raises StopIteration when
it's at the end).
gabor
--~
On Aug 23, 2006, at 6:25 PM, Adrian Holovaty wrote:
> Let's make this happen!
Indeed!
I've got some thoughts and preferences given all the ideas I've seen,
so here goes... Essentially, I think there's two tasks here:
1. Validation-aware models.
I very much want to be able to validate and sa
James Bennett wrote:
> On 8/24/06, JP <[EMAIL PROTECTED]> wrote:
> > I like James Bennetts's example a lot, but I'd like it more if the form
> > class were ModelForm, descending from a more general Form class that
> > would look much like the base Manipulator class of today.
>
> I think you're con
James Bennett wrote:
> I'm not so sure about that. The form itself was the thing that was
> "bad" and needs to be dealt with, so why *shouldn't* it be the
> exception?
It just feels right to me... When you're opening a file and you, say,
don't have permission you get OSError, not this "bad" file
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>
> Brantley Harris wrote:
> > Maybe it's a philosophic question, but I see it best
> > defined in the "model" space because then it provides a modular
> > process for views to leverage.
>
> Manipulators can (and do) serve not only as model save
On 8/24/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I think the piece on which I agree with JP is that a _form_ serving as
> an exception is counter-intuitive. I would prefer an exception to be an
> error dict that is then used to display them.
I'm not so sure about that. The form itself was t
On 8/24/06, JP <[EMAIL PROTECTED]> wrote:
> I like James Bennetts's example a lot, but I'd like it more if the form
> class were ModelForm, descending from a more general Form class that
> would look much like the base Manipulator class of today.
I think you're confusing me with someone else...
Dan Watson wrote:
> Actually that was one of my favorite pieces. I think it captures what's
> going on in a very intuitive way: try to create/update, if that fails,
> redisplay with errors.
I think the piece on which I agree with JP is that a _form_ serving as
an exception is counter-intuitive.
The tutorial says and mentions that it creates indexes explicitly.
The syncdb command runs the sql from 'sqlall' on your database for all
apps in INSTALLED_APPS that don't already exist in your database. This
creates all the tables, initial data and indexes for any apps you have
added to your pro
Yes, that worked.
But the documentation always seems to recommend running ./manage.py
syncdb after you set up your models. It should also create any indexes
you have defined.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
> I'm afraid that I find the idea in Brantley Harris's proposal of
> raising a Form as an exception as a form of flow control really
> counter-intuitive. Apologies and it's just my opinion of course, but it
> has a sort of "too clever" feel to me. Also, exceptions are very
> expensive, and I don'
I agree and disgree. :)
I like James Bennetts's example a lot, but I'd like it more if the form
class were ModelForm, descending from a more general Form class that
would look much like the base Manipulator class of today.
I'm afraid that I find the idea in Brantley Harris's proposal of
raising
Brantley Harris wrote:
> Maybe it's a philosophic question, but I see it best
> defined in the "model" space because then it provides a modular
> process for views to leverage.
Manipulators can (and do) serve not only as model savers. They can
authorize, register, send mail etc. Manipulator is j
20 matches
Mail list logo
