On Tue, Oct 28, 2008 at 8:18 PM, oggie rob <[EMAIL PROTECTED]> wrote:
>
> > {% for item in grocery_list %}
> > {{ item }}
> > {% default %}
> > Nothing to buy.
> > {% endfor %}
>
> Please, though - use {% else %}. Its totally clear what its referring
> to and else doesn't mean squat unless
Note, that this is actually a dupe of #3481.
Regarding, {% else %}, see what Malcolm said about it -
http://code.djangoproject.com/ticket/3481#comment:2
On Oct 29, 1:18 pm, oggie rob <[EMAIL PROTECTED]> wrote:
> > {% for item in grocery_list %}
> > {{ item }}
> > {% default %}
> > Nothing to
> {% for item in grocery_list %}
> {{ item }}
> {% default %}
> Nothing to buy.
> {% endfor %}
Please, though - use {% else %}. Its totally clear what its referring
to and else doesn't mean squat unless you see what the if (and in this
case, for) test is anyway, so I don't think this would
Hi there,
I propose a feature which we already discussed a bit before 1.0 in
ticket #6398 [1]. It's about a small enhancement to the "for" template
tag that would allow users to specify a default item to be shown in
case the given iterable is empty.
Currently that's also possible with this:
{%
On Wed, Oct 29, 2008 at 1:29 AM, Adam Nelson <[EMAIL PROTECTED]> wrote:
>
> Proposal:
>
> After running into numerous 'gotcha' type problems with django-contrib
> and django-hotclub on MySQL and looking at some of the MySQL code ,
> I'd like to propose that Django have an official minimum MySQL
yes, it is "Lazy" in the "not evaluated until asked for sense" but
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/django/core/context_processors.py", line 20, in auth
if hasattr(request, 'user'):
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
On Tue, Oct 28, 2008 at 11:00 PM, Ilya Novoselov
<[EMAIL PROTECTED]> wrote:
>
> There was a ticket http://code.djangoproject.com/ticket/3371,
> concerning adding builtin filter to get dict value by key name.
>
> Jacob set resolution to wontfix, explaining that this filter would be
> out of django
LazyUser is lazy and works fine. It's only triggered because of the
messages part of the processor so that's the root of the problem
(which is currently being talked about in another thread)
On Oct 29, 4:51 am, bo <[EMAIL PROTECTED]> wrote:
> well, not exactly.
>
> the "LazyUser" is the thing
On Oct 29, 5:50 am, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> From the looks of it, the patch onhttp://code.djangoproject.com/ticket/4604
> is heading this direction
> re: backwards compatible and part of contrib.sessions.
>
> Maybe SmileyChris can speak to both of these points and if it could
My web host is still using 3.32 on the majority of their servers. They
just started upgrading to 5 though and plan on getting all their
servers migrated by the end of the year. Though I dont use MySQL for
django so I dont care what version they are using. I use PostgreSQL,
which my host is
After further review, I did find some webhosts that are still using
the MySQL 4 series which would be restrictive for some Django 1.0
users.
MySQL 4.1 might be a better minimum.
http://mediatemple.net/webhosting/gs/faq.php
-Adam
On Oct 28, 12:29 pm, Adam Nelson <[EMAIL PROTECTED]> wrote:
>
On 10/28/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> > I think decoupling messages from contrib.auth is a worthy step to
> > making auth a little bit more reusable.
>
> Agreed. However, doing this in a
Proposal:
After running into numerous 'gotcha' type problems with django-contrib
and django-hotclub on MySQL and looking at some of the MySQL code ,
I'd like to propose that Django have an official minimum MySQL version
for the Django core and possibly a higher recommended version for
contrib,
well, not exactly.
the "LazyUser" is the thing that is not so lazy (yes i agree that the
messages are not lazy either), the Session is hit on the get_user
statement in auth() before the messages are even considered (see the
back trace).
The idea i am proposing is to make that entire
On Mon, Oct 27, 2008 at 8:59 PM, bo <[EMAIL PROTECTED]> wrote:
> thus i do not need
> django.core.context_processors.auth) but "contrib.admin" screams if it
> is not included.
I don't want to steer the thread off-topic, but I've been bitten by
this as well. My specific usecase is a project in
On Mon, Oct 27, 2008 at 7:06 AM, andybak <[EMAIL PROTECTED]> wrote:
> I remember seeing a couple of places where some extra template blocks
> could help with extending the admin (object-tools springs to mind).
> What are the pro's and con's of adding a sprinkling of new blocks?
There really
On Mon, Oct 20, 2008 at 12:33 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> I think decoupling messages from contrib.auth is a worthy step to
> making auth a little bit more reusable.
Agreed. However, doing this in a backwards-compatible manner is going
to be tricky.
> By doing so, however,
On Wed, Oct 22, 2008 at 10:06 AM, patrickk <[EMAIL PROTECTED]> wrote:
> IMHO, when using "order_with_respect_to", one should be able to order
> the inlines (stacked & tabular).
Yup, this has been on the todo list for quite some time. We even
discussed it at PyCon a couple years ago as we kicked
There was a ticket http://code.djangoproject.com/ticket/3371,
concerning adding builtin filter to get dict value by key name.
Jacob set resolution to wontfix, explaining that this filter would be
out of django builtin template engine scope. But what's that scope
then?
I don't think that "get"
On Tue, Oct 28, 2008 at 7:33 AM, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Who can set "ready for checkin"? You know the answer: Ticket triagers
>
> But who are they? I have some tickets which are only small changes incl.
> unittest.
Generally speaking, it should be set by:
1. Someone who is
Who can set "ready for checkin"? You know the answer: Ticket triagers
But who are they? I have some tickets which are only small changes incl.
unittest.
Most of them wait in the state "Accepted":
http://code.djangoproject.com/ticket/6160 Escaping of validation errors
21 matches
Mail list logo
