On Tuesday, September 15, 2015 at 12:16:03 AM UTC+2, jasbligh wrote:
>
> Then in the javascript call JSON.parse twice
>
No idea why you'd ever need to use that; var json = JSON.parse('{{
json_dumps|escapejs }}'); should be fine already, or do I miss anything?
That said, we should get rid of in
> it was too hard to do a generic one that could be used everywhere
The tag in argonauts works in HTML4, HTML5, and XHTML content, with or
without CDATA tags. The only place you cant use it is inside an [X]HTML
attribute.
--
You received this message because you are subscribed to the Google G
I know there was previous ticket about a json filter which came to the
conclusion it was too hard to do a generic one that could be used everywhere [1]
For the use case where the json is going to be in a script tag that won’t be
executed it seems to me like the approach in django-argonauts is per
> Having looked around my solution is to output the json string with {{
json_string|escapejs }}.
> Then in the javascript call JSON.parse twice
> JSON.parse(JSON.parse('"' + jsonString + '"'));
That doesn't seem nice at all. Is there any objection to putting the json
filter from django-argonauts
Help would be greatly appreciated, first time contributor, not 100% sure what
I’m doing.
Got stuck with the test suite over the week but back on track now.
There is a github repo here with my work [1]. The tests seem to be passing but
I haven’t created any new ones.
What is the best approach a
On Saturday, September 26, 2015 at 4:41:55 AM UTC+2, Gavin Wahl wrote:
>
> > which then only needs to go through the autoescape filter I think
>
> This is actually incorrect.
I'm very interested in getting this into 1.10. I can devote some time to it
to help.
When I looked at it before, based on the time I had available, it didn't
seem feasible for me to remove every single inline script. Especially with
form widgets that include templated javascript. Instead I was
> On 14 Sep 2015, at 11:52, Florian Apolloner wrote:
>
> Makes sense, depending on the actual parameters data attributes could make
> sense too for a few things. Oh, btw please do not handwrite JSON in
> templates, either do it in the view or use a filter to actually create JSON
> which then
On Monday, September 14, 2015 at 1:54:06 PM UTC+2, jasbligh wrote:
>
> Perfect, would you know where would be best to place the js in that case?
> (I've got the attribute working with the forms framework though)
>
Dunno, any existing file which has a few functions should do ;) If the form
attr
On 14 September 2015 at 11:52, Florian Apolloner
wrote:
>
>
> On Monday, September 14, 2015 at 1:17:37 AM UTC+2, jasbligh wrote:
>>
>> I'd propose solving as follows
>> 1) use the autofocus attribute when creating the form. This will work for
>> IE10+ http://caniuse.com/#feat=autofocus It can als
On Monday, September 14, 2015 at 1:17:37 AM UTC+2, jasbligh wrote:
>
> I'd propose solving as follows
> 1) use the autofocus attribute when creating the form. This will work for
> IE10+ http://caniuse.com/#feat=autofocus It can also be done by including
> a creating a few targeted one line js
Ticket #15727, dealing with adding support for the Content Security Policy
header, was last updated with the suggestion that the one thing should be
done is to make the admin site compatible by removing inline scripts.
I'd love to see this done, especially with the new design. I have done a
simila
12 matches
Mail list logo
