#7261 closed New feature (fixed)
Support for __html__ for Library interoperability
Reported by: | Armin Ronacher | Owned by: | Unai Zalakain |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | __html__ |
Cc: | miracle2k, oliver@…, Wil Clouser, ivank, jdunck@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | yes |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
The pylons developers proposed the __html__
special method to determine the HTML representation of strings which is currently implemented by Pylons for mako, Jinja2 and soon Genshi. Having support for that in Django would make it possible to use the autoescaping facilities of these template engines in Django.
The idea is that if an object implements __html__
which returns a string this is used as HTML representation (eg: on escaping). If the object is a str or unicode subclass and returns itself the object is a safe string type.
This Genshi ticket shows some details about it: http://genshi.edgewall.org/ticket/202
Attachments (2)
Change History (24)
comment:1 by , 17 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 16 years ago
comment:3 by , 16 years ago
This shouldn't be thought of as *replacement* for autoescaping, since that's not required, but as something that uses it for interoperability. It's a feature addition. It looks like the __html__
method will be something along the lines of
#! def __html__(self): return mark_safe(conditional_escape(self))
Possibly with a force_unicode
or force_str
call at the end, since it's not clear whether this method is expected to return an object that can be stringified or a bytestring or anything basestring-derived.
There's also the flip side to this, which is adjusting conditional_escape
to know how to handle objects with this special method name. That should only be two or three lines as well, by the looks of it.
Note, however, that there is at least one reason for not including it: it goes against Python's guidelines of not introducing methods with leading and trailing double-underscores. It's the one namespace that Python has really reserved for internal object-level methods since pretty much forever. We'll have to make a decision about whether breaking that rule is acceptable.
comment:4 by , 16 years ago
Cc: | added |
---|
comment:5 by , 16 years ago
Summary: | Support for __html__ for Library interobability → Support for __html__ for Library interoperability |
---|
comment:6 by , 15 years ago
Cc: | added |
---|
by , 15 years ago
implement html on SafeData for template engine interop
comment:7 by , 15 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:8 by , 15 years ago
Cc: | added |
---|
comment:9 by , 14 years ago
Where is the spec for how this __html__()
method is meant to work and what API guarantees it offers? Adding a method just to support introducing security problems isn't a good idea. Is there *any* documentation for how it's supposed to work?
comment:10 by , 14 years ago
How is that introducing security problems?
The spec is literally: "if an object has an html method it can be used to get a safe html representation of the object in unicode that is guaranteed to be convertible into an unicode string but might be a unicode string subclass". End of spec :)
comment:11 by , 14 years ago
Cc: | added |
---|
comment:12 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:13 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Accepted |
UI/UX: | unset |
comment:14 by , 11 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Patch needs improvement: | set |
comment:15 by , 11 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:16 by , 11 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:18 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:20 by , 11 years ago
Cc: | added |
---|
There is no reason this should not be in Django. I may write up a patch once I read up on how it's used everywhere. This could then easily replace the auto-escaping system which is in Django, for a better, standardized system.