Re: jQuery.tmpl() and Django
2011/5/27 Gábor Farkas: > On Fri, May 27, 2011 at 7:04 AM, Sean O'Connor wrote: >> A better approach would for Django to provide some tools and documentation >> to help people work around the conflict. One easy solution would be to >> provide a verbatim tag like what ericflo wrote >> at https://gist.github.com/629508. Another would be to provide >> documentation on tools that make it easy to load jquery style templates via >> ajax like icanhaz.js. > > (technically, there is an open jquery-templating ticket about making > the template-tag format customizable: > https://github.com/jquery/jquery-tmpl/issues/74) > > i had the same problem in the past (btw. mustache.js also uses the > two-curly-braces notation :-), > and unfortunately the verbatim tag did not solve the problem, because > sometimes you need > to use the django-templating INSIDE the jquery template > . > for example: > """ > . > . > > Are you sure to delete {{ name_of_thing }}? > > > > """ > > here i want the {{ name_of_thing }} to be handled by > jquery-templating, but the translation > should happen using the django-tags. > > so either i have to use the {% verbatim %} tag only around the places > where i have javascript-variables > (and not around the whole jquery-template), or i have to do the > translation in python, > and send them in as variables in javascript. both seem to be impractical. > > the approach i chose was to use a different variable-syntax > (instead of "{{ thing }}", i use "[[ thing ]]"), and before using the > template, > i simply replace those with the correct values. it's not nice, but > still the most practical solution i could find. > > gabor I wonder if verbatim as a filter makes more sense, for example:: Are you sure to delete {{ "{{ name_of_thing }}"|verbatim }}? The filter would then just return {{ name_of_thing }} back to the template. If you wanted to use a template variable as the name of the jQuery variable this approach would still fail. Now that I think about it maybe the replace tokens approach is the most flexible. {% verbatim "[[" "]]" %} Are you sure to delete [[ name_of_thing ]]? {% endverbatim %} You you could then choose the tokens that get replaced. - Sean > -- > 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, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: jQuery.tmpl() and Django
On Fri, May 27, 2011 at 7:04 AM, Sean O'Connorwrote: > A better approach would for Django to provide some tools and documentation > to help people work around the conflict. One easy solution would be to > provide a verbatim tag like what ericflo wrote > at https://gist.github.com/629508. Another would be to provide > documentation on tools that make it easy to load jquery style templates via > ajax like icanhaz.js. (technically, there is an open jquery-templating ticket about making the template-tag format customizable: https://github.com/jquery/jquery-tmpl/issues/74) i had the same problem in the past (btw. mustache.js also uses the two-curly-braces notation :-), and unfortunately the verbatim tag did not solve the problem, because sometimes you need to use the django-templating INSIDE the jquery template . for example: """ . . Are you sure to delete {{ name_of_thing }}? """ here i want the {{ name_of_thing }} to be handled by jquery-templating, but the translation should happen using the django-tags. so either i have to use the {% verbatim %} tag only around the places where i have javascript-variables (and not around the whole jquery-template), or i have to do the translation in python, and send them in as variables in javascript. both seem to be impractical. the approach i chose was to use a different variable-syntax (instead of "{{ thing }}", i use "[[ thing ]]"), and before using the template, i simply replace those with the correct values. it's not nice, but still the most practical solution i could find. gabor -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django and the new EU anti-cookie law
On 27/05/11 14:18, Hanne Moa wrote: > "From 26th May 2011 websites in the UK need to ask for permission > before they can set cookies not required for ‘essential’ means" > > http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-websites-illegal-what-you-need-to-know/ > > What cookies in Django are "essential"? When not logged in I see that > the csrf-token cookie is set, and when logged in there's the > session-cookie. Should one strive only to use csrf-protection (and > thus the cookie) only when it is needed? Are there other cookies set > by contrib apps? Should there be something about this in the docs? > " cookies is essential, you need need to get consent for these > other ones: " As the silktide blog points out [1], the ICO site itself [2] is still setting an ASP.NET session cookie before any 'opt-in', and clearly considers this 'essential'. It is also clearly *not* essential for some users - I could browse the site perfectly well with cookies blocked. So, they obviously consider it 'essential' for technological reasons - they do not have the technological/financial resources to produce a solution that doesn't automatically set a session cookie. On that grounds, we can easily argue the same for our sessions cookies. We can also argue that the CSRF cookie is essential for security reasons. It is also only sent when necessary - if you don't have a form that uses the token, it isn't sent. The only other cookie we send, as far as I know, is the language cookie. My interpretation of what I've read is that a site has to get consent for setting that. In theory I guess a site might need permission any time it puts anything in the session, since that is equivalent to setting a cookie. It's fairly depressing to think about the amount of money wasted by my government and EU government on making/complying with this new law, which will do nothing but waste the time and money of many more people. I'm hoping, however, that the first time this is properly tested in court, the law will be forced to turn into something more rational. Also, the previous set of UK laws regarding cookies were basically ignored by everyone. They apparently stated that you had to: * tell people how you use cookies, and * tell them how they could ‘opt out’ if they objected. I don't think I've been involved with making a site that was compliant with that, and I've never heard about anyone being prosecuted under those laws. Regards, Luke [1] http://blog.silktide.com/2011/05/cookie-law-delayed-for-one-year-first-example-of-new-laws-in-effect/ [2] http://www.ico.gov.uk/ -- "The one day you'd sell your soul for something, souls are a glut." Luke Plant || http://lukeplant.me.uk/ -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django and the new EU anti-cookie law
On 05/27/2011 08:18 AM, Hanne Moa wrote: > "From 26th May 2011 websites in the UK need to ask for permission > before they can set cookies not required for ‘essential’ means" > > http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-websites-illegal-what-you-need-to-know/ > > What cookies in Django are "essential"? When not logged in I see that > the csrf-token cookie is set, and when logged in there's the > session-cookie. Should one strive only to use csrf-protection (and > thus the cookie) only when it is needed? Are there other cookies set > by contrib apps? Should there be something about this in the docs? > " cookies is essential, you need need to get consent for these > other ones: " Django itself sets only these cookies: CSRF, language, contrib.sessions, and contrib.messages (if you're using one of the cookie-using backends). I am not a lawyer, and I haven't read the new EU guidelines in depth. Based on the description in the blog post you link, ISTM that CSRF and language cookies are likely defensible as "essential" to the user-requested service. I think the status of the session cookie (and probably the messages ones as well) are very much dependent on how they are used by the specific site in question. I'd be fine with a documentation patch listing more clearly what parts of Django may set cookies, to make it easier for Django users to comply with this ruling. I'd be opposed to any specific mention of this ruling in the patch, and certainly opposed to any attempt in the documentation to define which Django-set cookies are "essential" and which require user consent - legal advice related to particular legal jurisdictions is WAY out of scope for Django's documentation. Carl -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django and the new EU anti-cookie law
"From 26th May 2011 websites in the UK need to ask for permission before they can set cookies not required for ‘essential’ means" http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-websites-illegal-what-you-need-to-know/ What cookies in Django are "essential"? When not logged in I see that the csrf-token cookie is set, and when logged in there's the session-cookie. Should one strive only to use csrf-protection (and thus the cookie) only when it is needed? Are there other cookies set by contrib apps? Should there be something about this in the docs? " cookies is essential, you need need to get consent for these other ones: " yet-another-proof-that-politics-and-tech-don't-mix-ly yours, HM -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: jQuery.tmpl() and Django
On May 26, 11:59 pm, Jonathan Slenderswrote: > +1 for the verbatim tag. I think this is something that we need in > Django by default. > > But I think that ericflo his implementation is not truly verbatim. I > mean, that it will probably drop whitespace between "{%" and the tag > names. It may not be important for jQuery, but if we implement > verbatim, the output should be an exact copy of the verbatim contents. This is true. I couldn't find an easy way to implement a verbatim tag that was truly "verbatim" at the time without making changes to Django's internals. -Eric -- 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, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: jQuery.tmpl() and Django
At project level is impossible, because you don't know for sure which templates belong to which project. But it should be possible to define the markup syntax for a directory of templates. Embedded in the template is tricky, that's a chicken and egg problem. The language should be known, before we are able to parse this kind of meta information. We can also of course assume that we have the current syntax at the beginning, and have a template_tag like the following, which alters the lexer at that point. {% template_syntax "[%" "]%" %} But while it is possible and has it's uses, I'm really sure that there are enough people against a dynamic syntax. It is too easy for the end- users to screw this up, and abuse it... I think a verbatim/raw/cdata -like tag is sufficient. By the way, the syntax is defined in: django.template.base. {BLOCK_TAG_START,BLOCK_TAG_END,...} On 27 mai, 09:07, Michael Blumewrote: > Would it be possible to customize the markup Django uses for template > compilation, either at the project level, at compile-time, or embedded in > the template itself? > > -Mike > > On Thu, May 26, 2011 at 11:59 PM, Jonathan Slenders < > > > > > > > > jonathan.slend...@gmail.com> wrote: > > +1 for the verbatim tag. I think this is something that we need in > > Django by default. > > > But I think that ericflo his implementation is not truly verbatim. I > > mean, that it will probably drop whitespace between "{%" and the tag > > names. It may not be important for jQuery, but if we implement > > verbatim, the output should be an exact copy of the verbatim contents. > > > Further, because it is possible that other languages use the same {% > > verbatim %} syntax, we should be able to configure what the end-tag > > looks like. That way, we can nest {% verbatim %} tags. > > > For instance: > > {% verbatim "===" %} > > ... > > {% "===" %} > > > Cheers, > > Jonathan > > > On 27 mai, 07:04, Sean O'Connor wrote: > > > I think it would be a bit much for us to ask the jQuery crew to change > > their template language to avoid conflict with ours. Aside from the amount > > of backwards incompatible work we'd be asking them to do, they'd probably > > just end up with a new conflict with some other template language. At the > > end of the day this is also more of a symptom than an underlying problem. > > Even if we got the jQuery crew to change their syntax, there would still be > > other JS template languages with the same conflict (e.g. mustache.js). > > > > A better approach would for Django to provide some tools and > > documentation to help people work around the conflict. One easy solution > > would be to provide a verbatim tag like what ericflo wrote athttps:// > > gist.github.com/629508. Another would be to provide documentation on tools > > that make it easy to load jquery style templates via ajax like icanhaz.js. > > > > My vote is that we fix the problem once and for all on our end by > > providing compatibility tools and guidance instead of trying to tell the > > entire JS community to not conflict with out template syntax :) > > > > -- > > > Sean O'Connorhttp://www.seanoc.com > > > > On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote: > > > > Hello, > > > > > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery > > > > brach, uses some of the same syntax as Django in its templating > > > > markup, which is a bit of a bummer. I'm writing to see whether you > > > > think we should get in touch with the jQuery team to see if they could > > > > plausibly change it. > > > > > There are, obviously, quite a lot of templating languages out there, > > > > and some of them are bound to clash with Django, and that's not a > > > > problem. But Django and jQuery are often deployed together (jQuery is > > > > actually bundled with Django for use in the admin), making this clash > > > > especially annoying. > > > > > You might think this isn't an issue since JavaScript code should be > > > > served from static files anyway, but there's an added complication. > > > > One of the patterns jQuery.tmpl() recommends is nesting templates > > > > within a
Re: jQuery.tmpl() and Django
Would it be possible to customize the markup Django uses for template compilation, either at the project level, at compile-time, or embedded in the template itself? -Mike On Thu, May 26, 2011 at 11:59 PM, Jonathan Slenders < jonathan.slend...@gmail.com> wrote: > +1 for the verbatim tag. I think this is something that we need in > Django by default. > > But I think that ericflo his implementation is not truly verbatim. I > mean, that it will probably drop whitespace between "{%" and the tag > names. It may not be important for jQuery, but if we implement > verbatim, the output should be an exact copy of the verbatim contents. > > Further, because it is possible that other languages use the same {% > verbatim %} syntax, we should be able to configure what the end-tag > looks like. That way, we can nest {% verbatim %} tags. > > For instance: > {% verbatim "===" %} > ... > {% "===" %} > > Cheers, > Jonathan > > > On 27 mai, 07:04, Sean O'Connorwrote: > > I think it would be a bit much for us to ask the jQuery crew to change > their template language to avoid conflict with ours. Aside from the amount > of backwards incompatible work we'd be asking them to do, they'd probably > just end up with a new conflict with some other template language. At the > end of the day this is also more of a symptom than an underlying problem. > Even if we got the jQuery crew to change their syntax, there would still be > other JS template languages with the same conflict (e.g. mustache.js). > > > > A better approach would for Django to provide some tools and > documentation to help people work around the conflict. One easy solution > would be to provide a verbatim tag like what ericflo wrote athttps:// > gist.github.com/629508. Another would be to provide documentation on tools > that make it easy to load jquery style templates via ajax like icanhaz.js. > > > > My vote is that we fix the problem once and for all on our end by > providing compatibility tools and guidance instead of trying to tell the > entire JS community to not conflict with out template syntax :) > > > > -- > > Sean O'Connorhttp://www.seanoc.com > > > > > > > > > > > > > > > > On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote: > > > Hello, > > > > > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery > > > brach, uses some of the same syntax as Django in its templating > > > markup, which is a bit of a bummer. I'm writing to see whether you > > > think we should get in touch with the jQuery team to see if they could > > > plausibly change it. > > > > > There are, obviously, quite a lot of templating languages out there, > > > and some of them are bound to clash with Django, and that's not a > > > problem. But Django and jQuery are often deployed together (jQuery is > > > actually bundled with Django for use in the admin), making this clash > > > especially annoying. > > > > > You might think this isn't an issue since JavaScript code should be > > > served from static files anyway, but there's an added complication. > > > One of the patterns jQuery.tmpl() recommends is nesting templates > > > within a
Re: jQuery.tmpl() and Django
+1 for the verbatim tag. I think this is something that we need in Django by default. But I think that ericflo his implementation is not truly verbatim. I mean, that it will probably drop whitespace between "{%" and the tag names. It may not be important for jQuery, but if we implement verbatim, the output should be an exact copy of the verbatim contents. Further, because it is possible that other languages use the same {% verbatim %} syntax, we should be able to configure what the end-tag looks like. That way, we can nest {% verbatim %} tags. For instance: {% verbatim "===" %} ... {% "===" %} Cheers, Jonathan On 27 mai, 07:04, Sean O'Connorwrote: > I think it would be a bit much for us to ask the jQuery crew to change their > template language to avoid conflict with ours. Aside from the amount of > backwards incompatible work we'd be asking them to do, they'd probably just > end up with a new conflict with some other template language. At the end of > the day this is also more of a symptom than an underlying problem. Even if we > got the jQuery crew to change their syntax, there would still be other JS > template languages with the same conflict (e.g. mustache.js). > > A better approach would for Django to provide some tools and documentation to > help people work around the conflict. One easy solution would be to provide a > verbatim tag like what ericflo wrote athttps://gist.github.com/629508. > Another would be to provide documentation on tools that make it easy to load > jquery style templates via ajax like icanhaz.js. > > My vote is that we fix the problem once and for all on our end by providing > compatibility tools and guidance instead of trying to tell the entire JS > community to not conflict with out template syntax :) > > -- > Sean O'Connorhttp://www.seanoc.com > > > > > > > > On Thursday, May 26, 2011 at 11:14 PM, Ori Livneh wrote: > > Hello, > > > jQuery.tmpl(), a beta feature slated for inclusion in the main jQuery > > brach, uses some of the same syntax as Django in its templating > > markup, which is a bit of a bummer. I'm writing to see whether you > > think we should get in touch with the jQuery team to see if they could > > plausibly change it. > > > There are, obviously, quite a lot of templating languages out there, > > and some of them are bound to clash with Django, and that's not a > > problem. But Django and jQuery are often deployed together (jQuery is > > actually bundled with Django for use in the admin), making this clash > > especially annoying. > > > You might think this isn't an issue since JavaScript code should be > > served from static files anyway, but there's an added complication. > > One of the patterns jQuery.tmpl() recommends is nesting templates > > within a