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) a
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) are probably at the
point of accepting that we have to do it even
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 proposal:
- Your approach is very group/SQL-centric, rather than being
object/goal-centric. I would expect t
On Tue, 2007-04-10 at 16:30 +, James Stembridge wrote:
> 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
On Apr 15, 3:00 pm, tsuraan <[EMAIL PROTECTED]> wrote:
> So {{my_dict | objIndex:Value}} will evaluate Value in the context of
> the current Context, and then pass it to the filter? The HTML
> Template guide says that the argument must be in double quotes, so I
> assume it has to be a literal, ra
Django widgets caused site traffic to explode by 1000% thanks guys
http://www.teenwag.com/widget
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
Sounds complicated, and I don't think it's necessary. Malcolm's concern was
that this special debugger never be enabled in production. What user is
associated with a request really has nothing to do with whether the code is
running in production -- in order to test out changes in my app before th
Hum, yeah, so maybe we could add a permission that could be set to a
lambda user and that would allow the access to this debugger. It
wouldn't care if the account is disabled or not, so that could
simulate an unauthenticated user (if the app checks
user.is_authenticated() and user.is_active). I kn
But don't you want to be able to debug the code paths that run for all
requests, not just authenticated/staff/superuser?
On 4/15/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
>
> Or even require a superuser?
>
> On Apr 16, 6:00 am, "Baptiste" <[EMAIL PROTECTED]> wrote:
> > Oh, and maybe we can chec
Or even require a superuser?
On Apr 16, 6:00 am, "Baptiste" <[EMAIL PROTECTED]> wrote:
> Oh, and maybe we can check if request.user.is_authenticated() and
> request.user.is_staff() before enabling it ?
>
> On 15 avr, 19:58, "Baptiste" <[EMAIL PROTECTED]> wrote:
>
> > I am +10 on this patch.
> > I
> This is so easily taken care of by a filter, I'm not sure if it's
> worth the trouble of introducing to the core syntax.
>
> @register.filter
> def objIndex(value, arg):
> "Use objects as keys in dictionaries
> {{ my_dict|objIndex:Value }}"
> return value[arg]
>
> for exa
On Apr 15, 2:53 pm, "ludvig.ericson" <[EMAIL PROTECTED]> wrote:
> works better since it doesn't return the data if it exists, or am I
> missing something with name lookups?
The getattr version handles the case where new_class._meta.app_label
does exist, but is None.
--~--~-~--~~
In latest SVN (as of writing) you see this in said file:
48 if getattr(new_class._meta, 'app_label', None) is None:
49 # Figure out the app_label by looking one level up.
50 # For 'django.contrib.sites.models', this would be
'sites'.
51 new_class._me
Oh, and maybe we can check if request.user.is_authenticated() and
request.user.is_staff() before enabling it ?
On 15 avr, 19:58, "Baptiste" <[EMAIL PROTECTED]> wrote:
> I am +10 on this patch.
> If this debugger was disabled if DEBUG is False, that wouldn't solve
> the problem ? I mean, are they
This is so easily taken care of by a filter, I'm not sure if it's
worth the trouble of introducing to the core syntax.
@register.filter
def objIndex(value, arg):
"Use objects as keys in dictionaries
{{ my_dict|objIndex:Value }}"
return value[arg]
for example, is probably
I am +10 on this patch.
If this debugger was disabled if DEBUG is False, that wouldn't solve
the problem ? I mean, are they people who use DEBUG mode in
production ?
On 14 avr, 15:38, Marek Kubica <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm bringing this question up again, as no decision has been ma
Hi,
At this moment, in the new admin, widgets are not correctly handled :
fields with a choices argument are not represented by a but
by a simple input (#3268), FileField is a text input too... It is not
yet usable. Moreover, they are some blocking bugs in the admin (#3914,
#3974, #3973, ...).
I
> Any thoughts?
Ok, so I just tried installing the admin interface, and my code
appears to break that in all sorts of interesting ways. So, I guess
what I posted is pretty worthless right now. I'm still going to try
to get this working though, since I think it should be worthwhile.
--~--~-
Hi,
On Sat, 14 Apr 2007 09:42:26 -0700, anders conbere wrote:
> If you have many objects that differ by only one field, have you
> considered moving that one field into it's own model? That would
> allow you to to make "copies" by simply setting up a m2m relation.
Unfortunately, it's not that
20 matches
Mail list logo
