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 fun
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&q=kocherhans+django-admin#789da4389cf33295
Would it be crazy if w
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
cache(s
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 django-opensoci
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 ge
On Nov 14, 2007 9:13 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
> For shared cache backends, like Memcached it works fine. You just need
> to be sure that signal handlers will be registered in all processes
> (i.e. put them in models.py)
sorry, my bad - we do a similar thing but dynamic, and
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 dja
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 a
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 doctest
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
>
> http://code
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 --settings
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, se
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 lo
For shared cache backends, like Memcached it works fine. You just need
to be sure that signal handlers will be registered in all processes
(i.e. put them in models.py)
On Nov 14, 4:20 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
> On Nov 14, 2007 2:41 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
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, error_class=
On Wed, Nov 14, Jason Davies wrote:
>
> 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 solv
On Nov 14, 2007 8:41 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> So, to sum up, I'd prefer merges from trunk less often, but understand
> others may prefer more often. Even with frequent merges, I don't have
> to take the merge-- but cherry-picking is extra work.
We've never really enforced th
Hi, Todd. So this is two issues, then.
On Nov 14, 2007 9:04 AM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> Good point. In fact, I wasn't using --plain, but PYTHONSTARTUP wasn't
> being respected anyway. Any ideas why the heck that should happen?
No idea, sorry. :-) I'd attach with pdb and wal
On Nov 14, 2007 10:04 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> I'm not entirely convinced the overhead is all that terrible, especially given
> that:
>
> * Database writes are less frequent than reads.
> * Anybody overriding save is probably adding more overhead than this anyway.
>
> Maybe we
On Nov 14, 2007 9:44 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> The queue.dispatch is only necessary if dispatcher.queue has been
> invoked; if save is not overridden, dispatcher.queue is not invoked.
> Right?
Correct.
> Even so, it seems to me that the queue approach would need to be thread-
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, b
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 pr
On Nov 14, 2007 8: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?
The queue.dispatch is only necessary if dispatcher.queue has been
invoked; i
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 perh
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 queue
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 adj
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 someth
On Nov 14, 2007 2:41 PM, Sergey Kirillov <[EMAIL PROTECTED]> wrote:
>
> 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
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
frie
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" grou
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 PyDispatcher
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)
d
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 se
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 thi
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
37 matches
Mail list logo
