On 4/11/07, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> I consider this a wart and it's been bugging me for a while. So,
> sparked by some discussion in #django, here goes...
>
> I'd like it if template filters supported multiple arguments for real.
> Currently filters that need multiple arguments j
On 4/10/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > 2) (Jacob) Add a child class of DateTimeField that defines the
> > required pre_save behaviour.
> >
> Solution #2 seems the cleanest to me, and it has the advantage that
> docu
Hello,
On Mon, 09 Apr 2007 12:19:18 -0700, Armin Ronacher wrote:
> Alright. Patch here: http://pocoo.org/~mitsuhiko/django_debugger.patch
> Screenshot here: http://pocoo.org/~mitsuhiko/djangodebug.png
That's definitely cool. There are cases in which you'd like to have a
prompt to check what went
I have something similar to this in the Zyon's codebase. but I called
it 'preferences' (see http://zyons.com/preferences/ )
The zyons version allows for:
- constants at the site level (ie max blog comments can be different
on different sites)
- allows users (registered and anonymous) to set t
I consider this a wart and it's been bugging me for a while. So,
sparked by some discussion in #django, here goes...
I'd like it if template filters supported multiple arguments for real.
Currently filters that need multiple arguments just have to come up
with a delimiter and then do string parsi
I am not a fan of reusing the existing model fields classes for all
the reasons you specified.
How would a FileField or an ImageField work? How would the proposed
CreatedTimestamp/ModifiedTimestamp fields work?
ForeignKey? yikes.
The added confusion for users and developers who are extending or
c
In working a bit with this, I noticed something. Once these constant
definitions are moved outside the main field namespace, there's no
longer a clash of functionality between standard fields and these
constant values. That clash was the primary reason I had to recreate
the basic functionality of
On Tue, 2007-04-10 at 10:25 -0700, Gulopine wrote:
> On 4/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Given that logic (which, as I said, may or may not be a correct
> > recollection), I vote for Jacob's solution. In fact, it might be cleaner
> > to have CreationTimestamp and ModifiedTimest
On 4/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Given that logic (which, as I said, may or may not be a correct
> recollection), I vote for Jacob's solution. In fact, it might be cleaner
> to have CreationTimestamp and ModifiedTimestamp fields (both subclasses
> of DateTimeField) so that it'
Like I said, I wanted to do that this aftertoon and then I saw your
patch... which fits exactly to what I needed. It is imo an useful
change - and not only because I would need it - that should be
integrated in the core.
On 10 avr, 14:41, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Done:
>
>
On 4/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Given that logic (which, as I said, may or may not be a correct
> recollection), I vote for Jacob's solution. In fact, it might be cleaner
> to have CreationTimestamp and ModifiedTimestamp fields (both subclasses
> of DateTimeField) so that it'
Recently in [1], someone ran into a problem after installing 0.96.
Namely, the 0.95 egg was still on the system, and overriding the 0.96
install.
Could we maybe get a note in the install document to help people out
with this? I forsee lots of people asking about this in the near
future, as more p
Hi Philippe
On Apr 10, 1:41 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> http://code.djangoproject.com/ticket/3990
Perhaps a simpler way of handling things:
1. Leave the current behaviour of "editable=False" as is, i.e. if set
the field will not by default appear in the admin interface.
5) decorators for modify on save
http://groups.google.com/group/django-developers/browse_thread/thread/4cd631c225cb4e52/#
I am still working on the end implementation, I have many models which
implement some sort of dynamic update on save given a condition. The
auto_now and auto_add_now are just
On Tue, 2007-04-10 at 13:51 +0800, Russell Keith-Magee wrote:
> However, I haven't been able to find the original discussion leading
> to this decision in the archives (other than a reference in the early
> discussions about model validation [1]), so I haven't been able to
> establish the source
On 4/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> 1) Leave it completely up to the user to define their own auto_now equivalent.
>
> 2) (Jacob) Add a child class of DateTimeField that defines the
> required pre_save behaviour.
>
> 3) (Brian Beck) Add a 'default_condition' parameter - a
Sorry, it seems, that I misunderstood something, because I was reading
only this discussion, but not the ticket information.
Regards,
Aidas Bendoraitis aka Archatas
On 4/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Done:
>
> http://code.djangoproject.com/ticket/3990
>
> Please note
Done:
http://code.djangoproject.com/ticket/3990
Please note that the submitted is different from what we discussed. I
have created a new option for the AdminModel class and left the non-
editable fields out of the picture.
Aidas: what you're looking for is editable=False :)
--~--~-~--
Hi Ryan --
Please direct questions of this nature to django-users; django-dev is
used to discuss the development of Django itself, not to answer usage
questions.
To try to answer your question, though: have you tried phrasing your
queries in less than/greater than form (i.e. filter(lat__gt=-3,
l
Been following ticket 2358 ( http://code.djangoproject.com/ticket/2358
) with interest and have even emailed a few people listed as
participating in this effort but have not been able to get any sense
of how/if this is coming along. I've even offered to provide dev/test
assistance but received no
Gábor Farkas wrote:
> i'd like to know about Request objects... how "early" do you plan to
> switch to unicode?
>
> will request.GET/POST already contain unicode-keys + unicode-values?
>
> what about request.META?
>
>
> i would personally like to have GET/POST already contain unicode data.
>
Shouldn't there be a possibility to have fields that were not visible
in the admin at all, like sorting paths for multilevel objects (i.e.
categories), pickled objects, or other system data that makes no sense
to "normal human beings". I would propose to have some attribute like
visible=False or h
Hi guys,
I have submitted a patch : http://code.djangoproject.com/ticket/3987
and before you refuse it, I just want to explain why imo it is
useful ;-) !
At the moment, a ForeignKey (or any related field) is displayed in the
admin with a list of all the items of the database. That may be
powerfu
Malcolm Tredinnick wrote:
>
> What I'd really like from you guys (Michael, Ivan, Gábor -- and anybody
> else who wants to play along) is to see how the code fits in with your
> existing workflow. What are the bits that are still hard for you? What
> are the problems that aren't solved? I'm thinki
Hi,
I am currently making a mashup of the Weather Channel's RSS feeds
(temperature and wind speed data) and Google maps with Django. Briefly
it puts weather data on a map, e.g. sunny in London, rain in
Edinburgh. I am having problems with comparing longitudes and
latitudes in the database when
On Tue, 2007-04-10 at 12:13 +0200, Michael Radziej wrote:
> Hi Malcolm,
>
> Malcolm Tredinnick wrote:
> > It's a much tougher requirement on the developer. They have to change
> > every piece of their code. Instead, we can accept UTF-8 bytestrings or
> > unicode strings and large amounts of code
Hi Malcolm,
Malcolm Tredinnick schrieb:
> However, I'd like to hold off closing all those tickets until we merge
> the branch (maybe stick a unicode-branch keyword on them so we can find
> them later). They're not fixed for "trunk" purposes yet (and our
> understanding may change as people test t
Hi Malcolm,
Malcolm Tredinnick wrote:
> It's a much tougher requirement on the developer. They have to change
> every piece of their code. Instead, we can accept UTF-8 bytestrings or
> unicode strings and large amounts of code will work unchanged.
>
> There aren't actually that many places where
On Tue, 2007-04-10 at 19:53 +1000, Malcolm Tredinnick wrote:
> On Tue, 2007-04-10 at 10:02 +0200, Gábor Farkas wrote:
> > hi,
> >
> > i've been reading http://code.djangoproject.com/wiki/StringEncoding,
> >
> > and the idea seems to be, that for "Passing Strings Between Django and
> > the Devel
Malcolm Tredinnick wrote:
> On Tue, 2007-04-10 at 10:02 +0200, Gábor Farkas wrote:
>> hi,
>>
>> i've been reading http://code.djangoproject.com/wiki/StringEncoding,
>>
>> and the idea seems to be, that for "Passing Strings Between Django and
>> the Developer's Code",
>>
>> django will/should acce
On Tue, 2007-04-10 at 08:24 +0200, Gabor Farkas wrote:
> Malcolm Tredinnick wrote:
> > On Mon, 2007-04-09 at 18:56 +0400, Ivan Sagalaev wrote:
> >> As implemented now in unicode branch templates are loaded from files
> >> stored only in utf-8 (as far as I can read the code). However there's a
>
On Tue, 2007-04-10 at 10:42 +0200, Michael Radziej wrote:
> Hi,
>
> Malcolm Tredinnick wrote:
> > On Mon, 2007-04-09 at 18:35 +0400, Ivan Sagalaev wrote:
> >> Hello everyone!
> >>
> >> Malcolm has introduced DATABASE_CHARSET in changeset 4971[1] in a
> >> unicode branch. If I remember correctly
On Tue, 2007-04-10 at 10:02 +0200, Gábor Farkas wrote:
> hi,
>
> i've been reading http://code.djangoproject.com/wiki/StringEncoding,
>
> and the idea seems to be, that for "Passing Strings Between Django and
> the Developer's Code",
>
> django will/should accept both utf-8 encoded byte-string
Malcolm Tredinnick schrieb:
> Hi,
>
> On Mon, 2007-04-09 at 04:33 -0700, jedie wrote:
>> Why has django not a interactive AJAX traceback debugger?
>>
>> Using a interactive debugger you can play with objects at any point in
>> the error traceback.
>>
>> I known, a web shell is a open security h
Hi,
Malcolm Tredinnick wrote:
> On Mon, 2007-04-09 at 18:35 +0400, Ivan Sagalaev wrote:
>> Hello everyone!
>>
>> Malcolm has introduced DATABASE_CHARSET in changeset 4971[1] in a
>> unicode branch. If I remember correctly this setting was needed if we
>> have out internals in byte strings. But
hi,
i've been reading http://code.djangoproject.com/wiki/StringEncoding,
and the idea seems to be, that for "Passing Strings Between Django and
the Developer's Code",
django will/should accept both utf-8 encoded byte-strings, and
unicode-strings.
wouldn't it be simpler to only accept unicode
Gabor Farkas wrote:
> but what i don't understand, is: why is this an issue? can't we assume
> that the developer knows the encoding of his own files? and if he knows
> them, he should be able to easily recode them to utf-8, for example.
This is in many cases an emotional issue. Developers get
37 matches
Mail list logo
