I've just attached a new patch which (hopefully) makes everything work
in an acceptable way:
1. The argument ordering is still fixed, and you'll still want to pass
"instance" as a kwarg in most cases.
2. A ModelForm with neither model nor instance is an error.
3. A ModelForm which works on any of
OK, so after chatting a bit with Joseph on IRC I'm working on revising
my original patch. The changes it makes still need some discussion, so
I'll outline them here.
1. The "instance" argument to ModelForm.__init__() essentially becomes
a keyword argument defaulting to None, and moves out of the
On Dec 8, 2007 11:51 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> That's exactly what I'd imagined. Your example can be solved right now
> by the following:
>
> class LatLongForm(ModelForm):
> class Meta:
> fields = ('latitude', 'longitude')
>
> model_class = figure_out_latlong_model
On Dec 8, 2007 11:42 PM, Jorge Gajon <[EMAIL PROTECTED]> wrote:
> I have not received any email from the "django-updates" mailing list
> after December 1st.
>
I'm sorry, I didn't notice that on Dec 3rd someone wrote here about
this and Jacob replied that he is working on the problem.
I'll be mor
On Dec 8, 2007 11:29 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> So, I'm going to pretend you didn't say anything about rearranging
> positional arguments because a) it doesn't work, and b) your patch
> doesn't do that.
It does, it just makes 'instance' the last positional argument.
Whethe
On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I'm not sure I'd be a fan of a completely automated mechanism - Django
> has a certain sense of style and finess that isn't conveyed by simply
> aggregating all updates into a single message.
The intent of my first message was to propos
Hello,
I have not received any email from the "django-updates" mailing list
after December 1st.
After visiting its Google groups page I can see that indeed there
haven't been any updates to that mailing list.
http://groups.google.com/group/django-updates
Maybe the Trac hook responsible for sen
So, I'm going to pretend you didn't say anything about rearranging
positional arguments because a) it doesn't work, and b) your patch
doesn't do that. So, my response will assume that you are suggesting
that instance become a keyword argument rather than the first
positional argument, and that if
We briefly discussed adding row-level dependencies (this key is
dependent on x, y and z keys. It would be handled by storing an extra
object in memory that stored the dependencies for the object. A simple
reverse mapping if you will.
e.g.
- articles_article:1 has the object cache for the article
I added a patch which attempts to achieve a similar purpose without
changing the overal behavior of FileField in a more destructive
manner. The reasoning behind the patch is simple. The current code
defines the following behavior: when an instance of a model is
deleted, the file will also be delet
Since code speaks louder than words, I've opened ticket 6162[1] and
attached a patch which:
1. Makes "instance" the *last* argument to ModelForm.__init__().
2. Has ModelForm fall back to creating an instance of _meta.model if
the "instance" argument isn't supplied.
Updated tests and docs are als
On Sat, 2007-12-08 at 19:12 -0600, James Bennett wrote:
[...]
> In the first case, switching the positional order of the arguments
> would suffice; having 'instance' move after the 'data' and 'files'
> arguments would bring ModelForm back into line with "standard"
> newforms forms.
>
> In the se
I'd like to propose some refactoring of ModelForm to bring it into
line with the standard conventions of other newforms forms. Right now
there are two main issues:
1. A standard django.newforms.Form accepts POST data as its first
positional argument, while a ModelForm expects an instance of the
m
On 8 Dec 2007, at 20:14, Kevin Menard wrote:
> Shifting to a more personal stance, I never cared much for the term
> "Web 2.0". It seems too gimmicky. That's largely the impression I
> get with a Django 2.0 without a prior Django 1.0.
The other problem with Django 2.0 is that Rails just relea
On Nov 30, 2007, at 8:54 PM, Simon Willison wrote:
>
> On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>> I think we ought to call the release 2.0.
>
> I'm -0.5 on this (if that's possible). I understand the thinking
> behind it, but "1.0" isn't an arbitrary version number - it
A ticket already existed for it, I improved the patch, and I think
that now is ready for check in. http://code.djangoproject.com/ticket/5695
Could any commiter check it, please?
Thanks!
Marc
On Dec 8, 4:45 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On 12/7/07, Marc Garcia <[EMAIL PROTECT
Hello, In almost all my sites, I'm using a moderation zone, which it's
pretty much the same as the admin zone but I have per-row permissions.
Usually I build multiuser sites, and in my models I always add:
from django.contrib.auth.models import User
# This can be: Published, Pending, Rejected...
On 12/8/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Hi Devs,
>
> I've been missing the weekly updates that Clint Ecker was doing and so
> I thought I'd write in to pitch an idea and offer some help if I
> could. I'd say a good goal to keep these going would be to not rely
> in a single person a
On Sat, 2007-12-08 at 01:03 -0800, Antonio Cangiano wrote:
> On Nov 30, 1:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > I think we ought to call the release 2.0.
>
> Adrian, marketing matters. :)
> How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
> all the features
On Nov 30, 1:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I think we ought to call the release 2.0.
Adrian, marketing matters. :)
How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when
all the features listed above will be implemented?
Cheers,
Antonio
--
Antonio Cangiano
h
20 matches
Mail list logo
