On Tue, Sep 23, 2008 at 12:52 AM, David Cramer <[EMAIL PROTECTED]> wrote:>
> For me, personally, it would be great if this could accept callables
> as well. So you could store the username, like so, or you could store
> a choices field like:
>
>field = models.IntegerField(choices=CHOICES)
>
On Tue, Sep 16, 2008 at 2:41 AM, oggy <[EMAIL PROTECTED]> wrote:
> On Sep 15, 10:49 pm, "Justin Fagnani" <[EMAIL PROTECTED]>
> I can clearly see the appeal of the idea. Django can stay Javascript-
> agnostic, while the community could develop a PrototypeForms,
>
I think any discussion of denormalization needs to include aggregation
as well, since most uses will involve more than simply looking up one
value form a related model. I also think this is something definitely
to include in core. In my experience at least, denormalization occurs
a lot and leaves
Hey Zack,
I just got a chance to look at this, and I like it, but have one
suggestion. From a usage standpoint, wouldn't it be simpler to have
the decorator just be the signal name, like @pre_save? I can't see any
situation where you'd use a decorator for anything but connecting, so
the ".connect
I'm currently working on recursive inline editing using formsets, but
not in the admin. It's not completely working yet, but it's pretty
close. I've had to fix a number of things in formsets, and my patch
for that is in #8160. I got side tracked from that project for a
while, but I'll be back to i
On Wed, Sep 10, 2008 at 12:43 PM, Simon Willison
<[EMAIL PROTECTED]> wrote:
> Django proper was to modify Django's widget.render method to take an
> optional as_xhtml=True/False argument. The {% form %} tag would then
> set that argument based on context._doctype.
>
> I would also modify Context t
On Wed, Sep 10, 2008 at 12:30 PM, Simon Willison
<[EMAIL PROTECTED]> wrote:
> On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
>> For application-wide db connections, I think it'd be much easier and
>> more portable to choose the connectio
For application-wide db connections, I think it'd be much easier and
more portable to choose the connection in settings.py rather than in a
Model.
Manager.get_connection() is a great idea, but would it also make sense
to allow selecting the db via signals? That way you could make the
decision wit
On Tue, Sep 9, 2008 at 4:08 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> I've got most of it done locally, but I need to port it forwards to
> match recent changes on trunk
...
> if you haven't seen anything in a week, ping me again.
Thanks, that's great to hear.
-Justin
--~--~-~
I think one very important feature is submitting results back to
djangoproject.com for comparison. Since Django is so dependent on
underlying components it'll be very hard to compare results, but at
the very least we can track things like:
CPU type and speed
python version
memory (installed, free
I forgot to mention this as one of my ponies at djangocon, but I'd
really love to have multi-column fields. I particularly need this for
measurement and currency fields, which I think would be awesome to
have built-in.
So is anyone working on #5929? I see an email from Malcolm in March[1]
that me
ion 1.
There might be other issues with the patch too, especially since I
remove some methods that I'm still not sure are part of the API or
not, so I understand it probably won't make it into 1.0. I uploaded
the new patch along with a separate patch to change the test it's
failing.
-Justin
On Wed, Aug 20, 2008 at 8:39 AM, Brian Rosner <[EMAIL PROTECTED]> wrote:
> I am slightly unclear on what is allowed to
> be broken in this phase of Django development. I suspect it is okay
> since those methods are not explicitly documented and a quick note on
> the wiki would be decent. Someone p
hat it's to close to 1.0 change
anything.
On Sun, Aug 17, 2008 at 7:57 PM, Justin Fagnani
<[EMAIL PROTECTED]> wrote:
> I just noticed that BaseModelFormSet takes a queryset and populates
> its forms initial data from the queryset, but doesn't set its forms
> instance attrib
Uh.. disregard that. My mistake. I read the code wrong and
BaseInlineFormSet does not take **kwargs and pass them to
BaseModelFormSet.__init__(), so no you can't specify 'initial'. Which
is good.
-Justin
On Tue, Aug 19, 2008 at 12:54 PM, Justin Fagnani
<[EMAIL PROTECTED]>
On Tue, Aug 19, 2008 at 12:22 PM, Brian Rosner <[EMAIL PROTECTED]> wrote:
>Seems
> a bit overkill for the general case due to the unknown size of the
> queryset.
It is possible to specify both a queryset and initial data with a
ModelFormSet or InlineModelFormSet, and initial will override the
que
I ran into a problem trying to use inclusgion_tag() in combination
with a template that used the url tag with #5034 applied.
First, #5034, which patches the url tag to use request.urlconf if it's
been set, checks for an instance of RequestContext, rather than the
key 'request'. This could be chan
Ha, Magus is great. He's helped so many people, it's mind boggling.
Rather than ban him, I'd say he should get donations.
The problem on every IRC channel or email list is that often people
don't actually listen to the advice given to them, or read the
documentation pointed out to them. Magus may
Interesting problem. The real question is, what is the user's intent on a
query like that?
I have no idea. They probably are thinking along the lines of result #2 if
they don't understand the underlying SQL and #1 if they do. It's probably
not a good idea to assume either point of view. Using Sum
On Mon, Apr 28, 2008 at 2:10 PM, Nicolas E. Lara G. <[EMAIL PROTECTED]>
wrote:
> I didn't understand your point here. When is the data incomplete?
An example would be grouping people by age and averaging income, what should
the values of the name field be? None might make sense at first, as Honz
On Mon, Apr 28, 2008 at 12:11 PM, Mike Axiak <[EMAIL PROTECTED]> wrote:
> I would rather see two different parameters, e.g.::
>.save([force_update=True|False, force_create=True|False])
>
> That both default to False, and raise a ValueError when both are True.
>
I think this is by far the most
Hey everyone,
Good to see this has come up again. Congrats on getting the GSoC selection
Nicolas. The previous thread[1] has a lot of good discussion in it if anyone
here wasn't following that.
Obviously, I prefer the expression object API. I've actually been using it a
bit in an order processing
On Sun, Apr 27, 2008 at 8:18 PM, Ken Arnold <[EMAIL PROTECTED]>
wrote:
> Possible fix: define more clearly whether Django thinks that the model
> is in the database or not. Currently that's (IIRC) based on whether
> the model has a primary key. But as Malcolm points out, a semantic
> primary key
I started playing with subclassing the auth models today. What's nice is
that when you subclass User with, say, UserProfile, all users get a
.userprofile property, so the functionality of get_profile() is there for
free with the bonus of multiple User subclasses if that's needed.
I was thinking it
ead. It's not a lot of work. There
> are patches already made (and if they're not on trac I have them
> locally). I really don't want to have to switch to Storm, or Alchemy,
> because honestly, I love Django's approach. The more I'm building
> complex projects thou
On Sun, Mar 23, 2008 at 12:23 PM, Winsley von Spee <[EMAIL PROTECTED]>
wrote:
> perhaps I've just read over it, but how to you plan to handle not
> numeric types like datetime? In mysql you have to use something like
> "FROM_UNIXTIME(AVG(UNIX_TIMESTAMP(today))", but how should that be
> handled in
There must be a lot of us who have created a similar filter. My particular
version looks like this:
from django.template import resolve_variable
def lookup(value, key):
return resolve_variable(key,value)
so that it behaves like the normal attribute access.I use this to do things
like send a lis
27 matches
Mail list logo
