Re: custom function for autoescape
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 use case, but I see a bunch of sharp edges that will end up biting the user in unexpected ways. I think Luke's point (on the ticket) about XSS also bears repeating. Quoting: """ HTML autoescaping serves a very important security function — preventing XSS — I think it is OK to leave it as being an HTML only feature. Of course, there might be other types of output that would benefit in the same way, but they are not as important for a web framework. """ On top of that, alternate escaping schemes can be implemented as a template tag or filter. Doing it this way isn't quite as elegant as a systemic change to the rendering process, but with the edge cases described, the change wouldn't be an elegant systemic anyway. At the end of the day, it strikes me as a little too messy to be a core feature of the template language. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: No default comment_notification_email.txt, no docs
Hi Peter, On Nov 7, 9:41 pm, Peter Herndon wrote: > I just ran into a minor issue and thought I'd bring it to light. In adding > django.contrib.comments to a site I'm building, I found that when using > moderation and setting email_notification to True, that there is no default > template for comment_notification_email.txt included with the other comments > templates. There is also no documentation I could find that mentions what > context is provided to the template. I found it easily enough by reading the > email method of the CommentModerator class in > django/contrib/comments/moderation.py, but that seems less than optimal. > > I'm happy to open a ticket, but should the solution be to include a default > template, to add relevant documentation pointing out the customization > possibility, or both? In general, contrib.comments includes defaults for all the templates it needs, which suggests this one ought to be included too. On the other hand, contrib.auth doesn't include default templates for the email it sends for password-reset. Hmm. My inclination is to say that a simple default template for that email should be included, and the docs should include mention of the template and the context it receives. 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-develop...@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 Sprint this Saturday!
Hello everyone! Here in Argentina we're planning a Sprint[1] this Saturday to help with Django 1.3 We are going to participate from more than 4 Argentinian locations. We are very proud to count with Ramiro (cramm) one of the recently designated core commiters! There will be also, another Sprint in Berlin going on this Saturday[2]. See you then! [1] http://code.djangoproject.com/wiki/Sprint201011Argentina [2] http://code.djangoproject.com/wiki/Sprints -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Call for review and comment: #7539 (ForeignKey on_delete)
Last call for any concerns with the patch; planning to land it in the next 24 hours. 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-develop...@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: No default comment_notification_email.txt, no docs
On Nov 8, 2010, at 9:14 AM, Carl Meyer wrote: > Hi Peter, > > On Nov 7, 9:41 pm, Peter Herndon wrote: >> I just ran into a minor issue and thought I'd bring it to light. In adding >> django.contrib.comments to a site I'm building, I found that when using >> moderation and setting email_notification to True, that there is no default >> template for comment_notification_email.txt included with the other comments >> templates. There is also no documentation I could find that mentions what >> context is provided to the template. I found it easily enough by reading >> the email method of the CommentModerator class in >> django/contrib/comments/moderation.py, but that seems less than optimal. >> >> I'm happy to open a ticket, but should the solution be to include a default >> template, to add relevant documentation pointing out the customization >> possibility, or both? > > In general, contrib.comments includes defaults for all the templates > it needs, which suggests this one ought to be included too. On the > other hand, contrib.auth doesn't include default templates for the > email it sends for password-reset. Hmm. My inclination is to say that > a simple default template for that email should be included, and the > docs should include mention of the template and the context it > receives. > > Carl > Hi Carl, I filed ticket 14646, with a patch including a default template and some additional documentation. ---Peter -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: No default comment_notification_email.txt, no docs
On Mon, 2010-11-08 at 06:14 -0800, Carl Meyer wrote: > In general, contrib.comments includes defaults for all the templates > it needs, which suggests this one ought to be included too. On the > other hand, contrib.auth doesn't include default templates for the > email it sends for password-reset. Actually there is a template for it. It's found in django/contrib/admin/templates/registration/ and it's called password_reset_email.html - even though it doesn't contain any HTML. I have a truly marvellous explanation for these facts, but this e-mail is too small to contain it. Luke -- "I'm at peace with the world. I'm completely serene. I know why I was put here and why everything exists. I am here so everybody can do what I want. Once everybody accepts it, they'll be serene too." (Calvin and Hobbes) 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-develop...@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: custom function for autoescape
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(
> Context({'val': mark_safe("Joe's string")},
> autoescape=rtfescape)
> )
>
> 2) I don't use mark_safe on my safe input string and use addslashes to
> add the slashes
>
> Template("{{ val|addslashes }}").render(
> Context({'val': "Joe's string"},
> autoescape=rtfescape)
> )
>
> 3) I manually 'apply' addslashes.
>
> Template("{{ val }}").render(
> Context({'val': "Joe\\'s string"},
> autoescape=rtfescape)
> )
>
> But these do not produce the same output - 1 is different from 2 and 3,
> and is not what I intend.
>
Just for clarity could you say what the three outputs would be?
1) Joe\'s string
2) Joe\\'s string
3) Joe\\'s string
?
I would say that you would need to be aware of the escaping rules of the
mark up you are templating when writing your template, just like you need to
be aware of html escaping rules when you do any of these:
1)
Template("{{ val|force_escape }}").render(
Context({'val': mark_safe("This & that")})
)
2)
Template("{{ val|force_escape }}").render(
Context({'val': "This & that"})
)
3)
Template("{{ val }}").render(
Context({'val': "This & that"})
)
If you don't have knowledge of the escaping rules, and base the filters you
use based on that knowledge, you're in the same situation.
Flipped around, though, the |upper filter is not safe (in html and in
django), so that would mean that
Template("{{ val|upper }}").render(
Context({'val': mark_safe("Joe\\'s string")},
autoescape=rtfescape)
Would unexpectedly escape Joe's string to "JOE'S STRING", even though
upper is not unsafe in rtf.
That means that the safe-ness or not of each filter is determined by the
template markup being prepared.
So I see your point, and I see why it adds unwanted mess to Django. I just
thought I'd give more points of information. I'll probably even remove the
feature from Grantlee when I can, so thanks for the discussion.
All the best,
Steve.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Ticket #7817: Extending "with" and "include" tags.
On Thu, Nov 4, 2010 at 5:37 AM, silent1mezzo wrote:
> +1 for {% include "foo.html" x=1 y=2 %}
>
> This just seems more natural. My designer agreed based on the {% url
> %} tags.
>
+1 for using the = syntax here. My reasons have been mentioned above,
but to recap:
* and/as gets too verbose and difficult to read if you add more than a
couple variables
* HTML uses "=" to set attributes, so this shouldn't be a new paradigm
for template authors
-- Pete
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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.
Settings for a pure Oracle multi-db Django test suite setup
Hi all,
I'm setting up a Oracle XE instance on Linux to be able to test Django ORM
changes. This has so far resulted in a couple of small fixes and
a [1]wiki page documenting the process and hopefully any feeback
I get to this email.
Being a total newbie regarding Oracle is th reason I post this question after
a couple of hours trying to get our Django test suite working against
Oracle without errors to no avail.
I know that with this product only a 'XE' database is available and
that the Oracle
backend creates 'tablespaces' for every Django database.
I've reached the point where I can run most tests when
the DATABASES setting only includes the 'default' connection
but obviously I get a bunch of
ConnectionDoesNotExist: The connection other doesn't exist
errors and the following summary:
Ran 2712 tests in 1559.220s
FAILED (failures=28, errors=850, skipped=36, expected failures=1)
When I use a settings file, created after trial and error, containing:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xe',
'USER': 'djangotest',
'PASSWORD': 'foo',
},
'other': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'xeother',
'USER': 'djangotest2',
'PASSWORD': 'bar',
'TEST_TBLSPACE': 'tblspace_other',
'TEST_TBLSPACE_TMP': 'tblspace_tmp_other',
},
}
the auxiliary test-specific code of the Oracle bckend creates both tablespaces
and their respective users before running them and cleanly deletes all of it
afterwards. But then I get a lot of
DatabaseError: ORA-12520: TNS:listener could not find available
handler for requested type of server
errors and a summary like:
Ran 2746 tests in 2335.718s
FAILED (failures=36, errors=207, skipped=41, expected failures=2)
Has anybody had success with this setup i.e. one where the 'default and 'other'
alias pointing to such an Oracle product/install?. Is it possible at all?
If so, could you please share the relevant Django settings file (not
really, only
the DATABASES setting)?
Thanks,
--
Ramiro Morales
1. http://code.djangoproject.com/wiki/OracleTestSetup
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Settings for a pure Oracle multi-db Django test suite setup
Hi Ramiro
I've been working with Oracle during the sprints after last DjangoCon,
and had the same problem. I've been told by several people that
the second db can't be oracle and should be something else, like sqlite.
Here is my db settings.
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.oracle', # Add 'postgresql_psycopg2',
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'XE', # Or path to database file if using
sqlite3.
'USER': 'andrew', # Not used with sqlite3.
'PASSWORD': 'djangocon', # Not used with sqlite3.
'HOST': '192.168.2.33', # Set to empty string for
localhost. Not used with sqlite3.
'PORT': '1521', # Set to empty string for default.
Not used with sqlite3.
},
'other': {
'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2',
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': 'other_db', # Or path to database file if
using sqlite3.
'USER': '', # Not used with sqlite3.
'PASSWORD': '', # Not used with sqlite3.
'HOST': '', # Set to empty string for localhost.
Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not
used with sqlite3.
'TEST_NAME': 'other_db',
}
}
Andrew
On Nov 8, 2010, at 9:02 PM, Ramiro Morales wrote:
> Hi all,
>
> I'm setting up a Oracle XE instance on Linux to be able to test Django ORM
> changes. This has so far resulted in a couple of small fixes and
> a [1]wiki page documenting the process and hopefully any feeback
> I get to this email.
>
> Being a total newbie regarding Oracle is th reason I post this question after
> a couple of hours trying to get our Django test suite working against
> Oracle without errors to no avail.
>
> I know that with this product only a 'XE' database is available and
> that the Oracle
> backend creates 'tablespaces' for every Django database.
>
> I've reached the point where I can run most tests when
> the DATABASES setting only includes the 'default' connection
> but obviously I get a bunch of
>
> ConnectionDoesNotExist: The connection other doesn't exist
>
> errors and the following summary:
>
> Ran 2712 tests in 1559.220s
> FAILED (failures=28, errors=850, skipped=36, expected failures=1)
>
> When I use a settings file, created after trial and error, containing:
>
> DATABASES = {
>'default': {
>'ENGINE': 'django.db.backends.oracle',
>'NAME': 'xe',
>'USER': 'djangotest',
>'PASSWORD': 'foo',
>},
>'other': {
>'ENGINE': 'django.db.backends.oracle',
>'NAME': 'xeother',
>'USER': 'djangotest2',
>'PASSWORD': 'bar',
>'TEST_TBLSPACE': 'tblspace_other',
>'TEST_TBLSPACE_TMP': 'tblspace_tmp_other',
>},
> }
>
> the auxiliary test-specific code of the Oracle bckend creates both tablespaces
> and their respective users before running them and cleanly deletes all of it
> afterwards. But then I get a lot of
>
> DatabaseError: ORA-12520: TNS:listener could not find available
> handler for requested type of server
>
> errors and a summary like:
>
> Ran 2746 tests in 2335.718s
> FAILED (failures=36, errors=207, skipped=41, expected failures=2)
>
> Has anybody had success with this setup i.e. one where the 'default and
> 'other'
> alias pointing to such an Oracle product/install?. Is it possible at all?
>
> If so, could you please share the relevant Django settings file (not
> really, only
> the DATABASES setting)?
>
> Thanks,
>
> --
> Ramiro Morales
>
> 1. http://code.djangoproject.com/wiki/OracleTestSetup
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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-develop...@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.
