http://www.djangoproject.com/documentation/templates/#now
For "T", the docs say that it will output the "Time zone of this machine".
To me, this implies that it will read from tzdata. However, this actually
outputs the time zone specified in the project settings file, which I think
is the
Hey Honza,
On Tue, 2007-04-17 at 03:03 +0200, Honza Král wrote:
> On 4/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
> > [...]
> > > > btw. refactoring the queryset code is necessary for this to work, so
> > > > perhaps
On 4/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
> [...]
> > > btw. refactoring the queryset code is necessary for this to work, so
> > > perhaps we should focus our efforts there first. Maybe something will
> > > emerge
On Mon, 2007-04-16 at 21:55 +0800, Russell Keith-Magee wrote:
[...]
> > btw. refactoring the queryset code is necessary for this to work, so
> > perhaps we should focus our efforts there first. Maybe something will
> > emerge from that that would help us decide.
>
> Granted. At one point,
On 4/16/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> Short and sweet: since we're already planning some
> backwards-incompatible changes for the next release, how about we
> hammer out auto-escaping of template output while we're at it? Even
> those of us who don't like it (myself included)
Hoi,
A possible solution would be moving the debug view from the core into
a middleware. Then it's possible to replace the middleware and move
the debugger into a contrib package.
Regards,
Armin
--~--~-~--~~~---~--~~
You received this message because you are
Hi,
On Apr 16, 1:08 pm, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Armin, you're coming a bit late to this discussion. We had a few quite
> extensive threads months ago. If you seriously want to engage in this
> discussion, please read what's been written before. I understand that you
> cannot
filed in trac as ticket #4051
(http://code.djangoproject.com/ticket/4051)
webograph
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
On 4/16/07, Honza Král <[EMAIL PROTECTED]> wrote:
> besides, Django's queryset is very SQL-centric so far
To a large extent, yes, but no in some very important ways.
Article.objects.all() isn't the least bit SQL, although the mapping to
SQL is obvious. Preserving the object flavor of the ORM is
And that other setting, even to True, won't be used if debug is to
False (to prevent oblivions) ?
Moreover, to stop lambda users from accessing this debugger, maybe we
could enforce the admin to type a password in the console before
proposing its completes features ?
I mean, you have the debug
My preference would be to have it as either a package in contrib, or a
third party package that users can install. I don't know how easy it
would be to override Django's default debug handler but shouldn't be
too hard. This way we don't have any on-by-default situations, and it
should be fairly
On 4/16/07, Baptiste <[EMAIL PROTECTED]> wrote:
>
> Maybe some people use the development server in production... and
> maybe some people don't use it in devel !
> Precarious to take that for reference, don't you think ?
True. Tying the special debugger to the development server leaves people
Hi webograph,
On Fri, Apr 13, webograph wrote:
> i noticed that [] is not in the EMPTY_VALUES against which data is
> validated in newforms fields' default clean() function; this makes
> fields which usually return lists raise the ValidationError 'This field
> is required.' themselves instead of
Hi Russ,
great comments, thanks.
On 4/16/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> Hi Honza,
>
> Over the weekend, I tried responding to our last message inline, but
> my response kept getting long and confused. So, I've summarized my
> thoughts. I have three problems with your
On Mon, Apr 16, Armin Ronacher wrote:
>
> Hoi,
>
> -sys.maxint for autoescaping. I added support for that into jinja
> quite a while ago and it was pain in the ass. It makes things more
> complicated (speaking for return values and arguments of filters) and
> it blows up the implementation.
On 4/16/07, Armin Ronacher <[EMAIL PROTECTED]> wrote:
>
>
> Hoi,
>
> -1 for the database interaction. The debugger should also work if the
> database is fucked up.
Mind the language, please. This is a formal mailing list discussing serious
issues. Keeping the language civil is just one way we
The current admin (and the newforms one) doesn't allow enough
customization to make it user-friendly. That may be a feature, but
that is really boring to need to write its own admin because of the
limitations of the existing one.
In my case, I just have a ForeignKey to an User. At the first save,
On Mon, 2007-04-16 at 03:08 -0700, Armin Ronacher wrote:
> Hoi,
>
> -sys.maxint for autoescaping. I added support for that into jinja
> quite a while ago and it was pain in the ass. It makes things more
> complicated (speaking for return values and arguments of filters) and
> it blows up the
Hoi,
-sys.maxint for autoescaping. I added support for that into jinja
quite a while ago and it was pain in the ass. It makes things more
complicated (speaking for return values and arguments of filters) and
it blows up the implementation. Not worth the work.
Regards,
Armin
Maybe some people use the development server in production... and
maybe some people don't use it in devel !
Precarious to take that for reference, don't you think ?
On 16 avr, 01:45, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> Sounds complicated, and I don't think it's necessary. Malcolm's
Hoi,
What about using the Jinja approach?
{{ foo.bar.baz }}
is the same as
{{ foo['bar']['baz'] }}
So it's possible to use variables using this (where bar is a
variable):
{{ foo[bar].baz }}
Regards,
Armin
--~--~-~--~~~---~--~~
You
On Mon, 2007-04-16 at 08:58 +, [EMAIL PROTECTED] wrote:
>
> I don't think one it's possible to add to the "fields" admin option,
> so you'll end up having all editable fields in it:
>
> class MyModel()
> field1 = models.CharField(editable=False)
> field2 = models.CharField()
>
I don't think one it's possible to add to the "fields" admin option,
so you'll end up having all editable fields in it:
class MyModel()
field1 = models.CharField(editable=False)
field2 = models.CharField()
...
fieldn = models.SomeField()
Class MyModelAdmin()
fields =
On Mon, 2007-04-16 at 09:04 +0200, Michael Radziej wrote:
> Hi,
>
> Malcolm Tredinnick wrote:
> > What do you see as the currently undecided issues? We seemed to have
> > quite a good consensus after the innumerable earlier threads and the
> > implementation I wrote has been kept up to date by
Hi,
Malcolm Tredinnick wrote:
> What do you see as the currently undecided issues? We seemed to have
> quite a good consensus after the innumerable earlier threads and the
> implementation I wrote has been kept up to date by Michael Radziej
> (except for the admin portion, which I can update to
On 4/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On or off by default seemed to be the only debate (and it's not really a
> debate -- Adrian didn't like it).
I don't *like* it, but I've come around to accepting that it's better
for us not to point the gun at a developer's foot and say
On Mon, 2007-04-16 at 00:54 -0500, James Bennett wrote:
> Short and sweet: since we're already planning some
> backwards-incompatible changes for the next release, how about we
> hammer out auto-escaping of template output while we're at it? Even
> those of us who don't like it (myself included)
27 matches
Mail list logo
