Hi all,
While using templates to produce something other than HTML (latex by
the way), I wanted to use my own escape function, instead of the
HTML-oriented default in autoescape.
This is of course not too difficult with filters and turning of
autoescape, but it would be very nice if I could get t
Hi Will,
I've reopened the ticket, because that's elegant enough for me.
I remember having this discussion in IRC either with you or someone
else a while back and couldn't come up with any negatives to providing
this, as long as obvious caveats of tags/filters potentially relying
on the original
On Thu, 2010-11-04 at 17:24 +0100, Will Hardy wrote:
> I've attached a simple patch to the ticket [2] and would be happy to
> write tests and documentation if this approach is enough to overcome
> the "wontfix". Have I overlooked something?
I think the devil is in the details. If we go for a simp
Thanks for following up, Luke.
I understand your point of view, but personally, I'm fine with an "all
bets are off using built-in filters/tags" clause on a custom escape
method.
While you'd expect that addslashes would just work, I'd take the
opposite expectation and assume that any filter / tag u
Thanks for the explanation and perfect example Luke.
I thought I would try to be helpful and went through the source code
for all the filters and categorised them (see below). There are 12
filters that can't be used (8 are for html only anyway), 24 filters
may fail unpredictably (like your example
On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote:
> Thanks for following up, Luke.
>
> I understand your point of view, but personally, I'm fine with an "all
> bets are off using built-in filters/tags" clause on a custom escape
> method.
> While you'd expect that addslashes would just work, I'
On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote:
> I too would like to know other's thoughts.
Is there any other core dev who would like to weigh in on this?
Basically, the proposal is to add custom autoescaping, by passing a
callable as a keyword argument to Context.
The problem is that w
On Sat, Nov 6, 2010 at 11:16 PM, Luke Plant wrote:
> On Thu, 2010-11-04 at 19:06 -0700, SmileyChris wrote:
>
>> I too would like to know other's thoughts.
>
> Is there any other core dev who would like to weigh in on this?
Reading over the discussion, I'm in the same camp as Luke. I can see
the u
Hi,
Sorry I'm late to this thread. I've been working hard on i18n.
Luke Plant wrote:
> Logically I would expect the following 3 to produce the same output:
>
> 1) I use mark_safe on my safe input string and use addslashes to add
> the slashes
>
> Template("{{ val|addslashes }}").render(
> Conte
> Reading over the discussion, I'm in the same camp as Luke. I can see
> the use case, but I see a bunch of sharp edges that will end up biting
> the user in unexpected ways.
Thanks for dropping by :-) I think I've managed to remove the sharp edges.
The main problem in this thread is that the def
On Wed, 2010-11-10 at 13:04 +0100, Will Hardy wrote:
> > Reading over the discussion, I'm in the same camp as Luke. I can see
> > the use case, but I see a bunch of sharp edges that will end up biting
> > the user in unexpected ways.
>
> Thanks for dropping by :-) I think I've managed to remove th
Hi Luke,
> First, you depend only on the name of the function - so one that shadows
> a builtin filter won't be treated correctly (as you noted on the
> ticket).
This is true, I really hated this bit. The only thing that might work
is "libraryname.filtername" if it's possible to identify exactly
12 matches
Mail list logo
