Collin Grady wrote:
> Are you seeing this behavior in admin? If so, I believe that is what is
> actually at fault, since it hard-sets m2ms, which would clear anything
> set in save().
I know Russ didn't take much of a liking to this idea last time I mentioned
it, but...
That's why I say this
Joseph Kocherhans wrote:
> Hey Todd, I haven't looked at you patch, but here's what Russ
> mentioned when I asked:
>
> http://groups.google.com/group/django-developers/browse_thread/thread/fb148adb454b74ef/789da4389cf33295?lnk=gst=kocherhans+django-admin#789da4389cf33295
Would it be crazy if we
On 11/14/07, Marinho Brandao <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I created django-gadget [1] contrib. I see a great future for Google
> Gadgets with iGoogle, Google Desktop, OpenSocial and Android
> applications, this is my motivation to create it.
>
> I think it can be util to be added to
Any chance of adding signals to ManyToMany fields?
example usage:
- I have a perm_cache -- that I'm pretty sure django.contrib.auth also
has.
- I have instance caching, or memcache that perm cache (or in our
case, both).
- I update that perm_cache, in the admin, and need to reset the perm
Hi all,
I created django-gadget [1] contrib. I see a great future for Google
Gadgets with iGoogle, Google Desktop, OpenSocial and Android
applications, this is my motivation to create it.
I think it can be util to be added to contrib package. Or can be util
to other projects like
Just noticed an escaped string in my template due to:
{{ image.caption|default:"No caption" }}
It seems like to me that we should trust that string constants in
template variable tags are safe since they are directly in the
template author's realm, yes?
The only way I could figure out how to
Patch provided in
http://code.djangoproject.com/ticket/5943
On Nov 14, 2007 4:36 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
>
> On 11/14/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > Hey Russ,
> >
> > It looks like you made it impossible to call user-supplied commands
> > using
On Nov 15, 7:55 am, Luke Plant <[EMAIL PROTECTED]> wrote:
> You would have to change the middleware so that it does
> its 'rejection' business in process_view() instead of
> process_request() -- it would check the view for the flag, and require
> the CSRF token if it wasn't found.
>
> To me, this
On Nov 14, 2007 3:00 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
...
> And no, I'm not making a ticket for it yet, because it occurred to me
> while working on it, that it doesn't require any changes to
> PyDispatcher itself. That means, Jeremy, that you can just drop this
> somewhere and use it
On Nov 14, 2007 8:55 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I dunno, that's all just off the top of my head, but maybe it could work.
Well, I did a little digging and put together something that seems to
work. And when I say "seems to work", I mean that there are almost 100
lines of
On 11/14/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> Hey Russ,
>
> It looks like you made it impossible to call user-supplied commands
> using django-admin.py, even if the user specifies a --settings option
> which would give the apps and thus provide the commands. My patch for
>
>
Hey Russ,
It looks like you made it impossible to call user-supplied commands
using django-admin.py, even if the user specifies a --settings option
which would give the apps and thus provide the commands. My patch for
http://code.djangoproject.com/ticket/5516
specifically handles the
http://pyamf.org/wiki/DjangoHowto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group,
On Wed, 2007-11-14 at 18:21 +0100, Michael Radziej wrote:
[...]
> Now, either the super block has been created with autoescaping on and thus
> should
> be safe, or autoescaping has been intentionally switched off for it. In
> either case, I don't see much use for escaping it again.
Yes, this
On Saturday 10 November 2007 17:14:19 Gary Wilson wrote:
> By build it into admin, do you mean build it into newforms?
>
> Possibly changing BaseForm from:
>
> class BaseForm(StrAndUnicode):
> def __init__(self, data=None, files=None, auto_id='id_%s',
> prefix=None, initial=None,
Hi,
> On Nov 14, 2007 9:37 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> > This is neat and all, but I don't think at actually solves the problem at
> > hand.
> > If save is not overridden, when does queue.dispatch() get called?
>
> If save isn't overridden, queue.dispatch() wouldn't be called,
Good point. In fact, I wasn't using --plain, but PYTHONSTARTUP wasn't
being respected anyway. Any ideas why the heck that should happen?
At any rate, I don't think it matters whether you use --plain or not.
If you use --plain, you'd expect to get normal behavior for typing
python at a terminal
On Nov 14, 1:59 pm, Rudolph <[EMAIL PROTECTED]> wrote:
> May be I found one corner case. But I'm not sure if this is a bug or a
> feature. When using {{ block.super }} is will be escaped, which is
> IMHO not the common desired result. One can solve this by using
> {{ block.super|safe }}, but
On Nov 14, 2007 9:37 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> This is neat and all, but I don't think at actually solves the problem at
> hand.
> If save is not overridden, when does queue.dispatch() get called?
If save isn't overridden, queue.dispatch() wouldn't be called, because
the
I had been considering switching to the GIS branch before the sprint,
but the main concern I have is that getting up on GIS features and
bugfixes also means getting up on trunk features. As an example, in
[6671], auto-escape landed on trunk. I imagine that'll take me about
a week of work to
On Wed, Nov 14, 2007 at 08:55:09AM -0500, Marty Alchin wrote:
> On Nov 14, 2007 12:21 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Jeremy's still got a valid problem, though, but I'm not sure
> > reintroducing pre_save() and post_save() is a necessary step yet.
> > Hopefully there's
Thank you very much!
May be I found one corner case. But I'm not sure if this is a bug or a
feature. When using {{ block.super }} is will be escaped, which is
IMHO not the common desired result. One can solve this by using
{{ block.super|safe }}, but perhaps it's even more template-developer
And, of course, adding a queue to the dispatcher would decouple this
solution from save() and make it usable in any signal handling code.
-Gul
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
On Nov 14, 2007 12:21 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Jeremy's still got a valid problem, though, but I'm not sure
> reintroducing pre_save() and post_save() is a necessary step yet.
> Hopefully there's something else we can do.
I wonder if there's a way to modify
Hi all
In my project I frequently encountered a situation where I need to
cache some data, and then invalidate it on signal.
So I wrote following decorator:
def cached(slot_name, timeout=None):
def decorator(function):
def invalidate():
cache.delete(slot_name)
On Nov 14, 2007 4:02 AM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> I submitted a patch as http://code.djangoproject.com/ticket/5936
>
> Should be an easy change, I hope.
>
>
Hi, Todd.
Were you using --plain and still wanting the history and tab
completion, or was use_plain being incorrectly
As I've just mentioned on django-users, I finally arrived at a point
where I'm happy with the forwards-porting of the auto-escaping changes
and they've been committed in r6671.
There may be a few corner cases in some of the contrib apps that I've
missed through not using them very much, but I
I submitted a patch as http://code.djangoproject.com/ticket/5936
Should be an easy change, I hope.
On Nov 13, 2007 6:24 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> Deryck Hodge said the following:
> > It's the variable that says whether or not the option --plain was
> > used. It determines
28 matches
Mail list logo
