It seems silly that currently the auth message system calls
get_and_delete_messages for every request context (assuming you have
the auth context processor enabled, like it is by default).
1. You lose messages if you don't actually check for them
2. If you didn't check for it, and therefore won'
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
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 15, 6:02 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Would it be crazy if we got rid of django-admin.py and manage.py and replaced
> them with one "django" command to rule them all?
Sounds great to me!
--~--~-~--~~~---~--~~
You received this message because
So my template looks like: {{ group|caps }} (`group` is a Model object
and the `caps` filter just capitalizes the first letter) and I'm stuck
with double escaping.
The problem is, that it still gets double-escaped. Django's
FilterExpression checks to see if the incoming object is SafeData, but
at
PS: I've never even noticed the built-in `capfirst` filter until just
now, but mine was pretty much identical. The built-in one doesn't
solve this problem either.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Djang
On Nov 22, 8:46 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > The problem is, that it still gets double-escaped. Django's
> > FilterExpression checks to see if the incoming object is SafeData, but
> > at this stage it is a Model object
On Nov 23, 8:18 am, Goutham DL <[EMAIL PROTECTED]> wrote:
> Hi,
> Iam new to this community. I would like to know more about the django
> ORM(i.e its internal workings). Can someone provide some good links
> for this?
Hi Goutham,
If you're new to the community, ensure you have a good understandi
On Nov 22, 10:48 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> P.S. However I think you try to shoot yourself in the foot by tying
> general unicode representation of an object to work only for HTML. I'd
> rather leave it to some special filter.
Probably. I'm definitely being lazy ;)
But the bu
Hi Atsushi,
First, if you are going to post code, you should be creating a ticket
in our bug management system [1] rather than just putting them in an
email here.
Second, you can already override admin templates, as explained in the
second step of the templates [2] and the exact details are expl
On Nov 29, 9:28 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I've fixed it, after a fashion, in r6721.
Why no tests?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
On Nov 29, 12:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Drop them in a ticket and I'll commit them.
http://code.djangoproject.com/ticket/6049
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django devel
On Dec 1, 5:24 am, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On the issue of what to call 1.0, I like Max Battcher's idea of adopting an
> Ubuntu-like date-based version. Puts some useful information (how old is
> it?) into the release name and avoids preconceived notions of
> stability/complet
On Dec 1, 5:00 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> To a python developer who is unfamiliar with django's magic limiting
> syntax, the slice there looks unnecessary.
If/when we get a __nonzero__ method, it will be unnecessary.
--~--~-~--~~~---~--~~
I tried actually using lazy today for something and couldn't get it to
work.
It seems to me that the current implementation is basically broken.
For example, I was trying to do lazy(my_function, list)
__proxy__.__init__ tries to setattr(self, k, [promise]), but that
won't actually work for any ma
On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> What method?
lazy()
Maybe I just don't get how it is supposed to work, but the setattr
line seems wrong, at least for setting special method names.
Also confusing is that the docstring says "Results are not memoized;
the functio
On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> lazy() is complex enough without adding things we don't need.
I guess this is my point. It seems that lazy() has been made overly
complex for little gain.
> If there's a legitimate case where Django core needs this extra
> functi
On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > lazy()
>
> Of course it works. We're using it throughout Django for lazy
> translations.
It only just works :P
Currently a lazy object isn't considered an instance of its
resultclasses
So you can't do: isinstance(my_lazy_string
On Dec 5, 2:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > It only just works :P
>
> it's called Fit For Purpose. You've yet to demonstrate somewhere in
> Django we need all these extra levers of which you speak.
The lazy __proxy__ class is full of magical bits, which I don't really
get
Changeset 6299 [1] added some "useful" methods and attributes to
AnonymousUser.
One of these attributes is is_active = True
This is a change in functionality, because previously if you used
(like I was) {% if user.is_active %}, it would be only true for real
users who were active. Now it's true
On Dec 10, 2:41 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> The current app_directories template loader has always bugged me because it
> is:
>
> 1) inefficient - all application template directories are added as global
> template directories and are searched each time by the template loader.
On Dec 11, 1:01 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I suspect is_active should be False for those users (since they
> cannot log in and that's the point of is_active). So I'd probably be +1
> for changing is_active to False on AnonymousUser.
Ok, http://code.djangoproject.com/ticke
On Dec 13, 9:19 am, "Robert Coup" <[EMAIL PROTECTED]>
wrote:
> On 13/12/2007, Thomas Güttler <[EMAIL PROTECTED]> wrote:
>
> > How can you check that only authorized users can access
> > some files?
Thomas, you might want to try out http://code.djangoproject.com/ticket/3583
It needs some testing/
On Dec 17, 6:52 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > I've been working on a new version of the session messages ticket and
> > was looking at making the "messages" context variable lazy - it seems
> > silly
http://code.djangoproject.com/ticket/2891 was marked as a wontfix by
jacob after "discussion with Malcolm".
Neither Collin or myself (or several others on IRC) can see a reason
why that this would cause any big disruption.
Mr Trier even mentions it on his blog today as an example of a silly
defa
What I find mildly amusing is Malcolm's comment in the ticket [1]
which is pretty much the opposite of what he's saying now. In his
defence, he did say he would have to think about it for a bit
longer ;)
In any case, before I wrote the backwards-incompatible patch, I wrote
one that is pretty much
On Dec 20, 12:41 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007 4:26 AM, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> > What I find mildly amusing is Malcolm's comment in the ticket [1]
> > which is pretty much the opposite of what he
Haven't really thought about this too much, just wanted to throw the
idea out (mainly for Malcolm)
Currently, widgets are conditionally escaped [1]. Malcolm points out
that "This still isn't perfect behaviour (since it's unaware of the
current context's auto-escaping setting)..."
If the template
Just wanted to point out a discussion in django-users which is a bit
of a worry regarding session behaviour:
http://groups.google.com/group/django-users/browse_thread/thread/f7d7f737a5a76fa4/434e0ae7641153d9#434e0ae7641153d9
Anyway, I'm off on a holiday for two weeks, so I expect to come back
to
On Feb 6, 9:43 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> It already results in a broken site, we're now just being a lot clearer
> about that.
Actually, it only resulted previously in a broken site if the extended
template was being used in more than one depth of inheritance.
>
> Still
I notice that this new triage state snuck in recently.
Does this mean that all the "*-fixed" tagged tickets should be moved
to this state? (http://shurl.org/fixed-on-branch-report)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Go
I'd suggest moving install to a how-to rather than a topical guide.
Perhaps deployment could go under there, too? They seem closely
related.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
On Apr 8, 10:46 am, Mike Axiak <[EMAIL PROTECTED]> wrote:
> but if Django were to "support" pre-1900
> dates, then it stands to reason code wouldn't break if written like
> this::
>
> instance.field.strftime("%Y-%m-%d")
Actually, I've backpedalled a bit in my new patch (uploaded just now).
No
On Apr 22, 1:15 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
wrote:
> Hello Django Developers,
>
> I plan to assist Jacob complete a major portion of the ToDo [1] list
> that he has at the current moment. Hopefully by the end of this
> summer, the django-newcomments framework will be able to make qui
The current behaviour of BooleanField kind of negates the need for
NullBooleanField.
Contrary to the docs (and I'm pretty sure there's a ticket for it) a
BooleanField(required=True) doesn't actually fail validation if a
widget.
Personally, I like this behaviour better. Would we be losing any
fun
In the db-api docs under "one-to-one relationships", it still reads:
The semantics of one-to-one relationships will be changing soon, so we
don’t recommend you use them.
Is this still relevant after qs-rf? It seems like it is just more
"undocumented" than "changing semantics" now.
--~--~---
You were using a new feature (albeit the wrong one) so that's not
really a backwards incompatible issue, is it?
On May 6, 1:55 pm, David Cramer <[EMAIL PROTECTED]> wrote:
> Can someone add it to the BackwardsIncompatibeChanges page?
>
> I saw the warning, and briefly skimmed over the page and swi
A working patch is sitting in http://code.djangoproject.com/ticket/3121
Jacob: any reason you promoted to "accepted" rather than "checkin"?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
T
301 - 338 of 338 matches
Mail list logo
