Mike Orr wrote: > * Convert the HTML-generation functions to use ElementTree. These > can be used by Genshi directly but will need a new default filter for > Mako. These will probably be moved from webhelpers.rails.* to > webhelpers.html.
Doesn't only the dev version of ET has an HTML serializer? Obviously that's important. I would like if the objects also had a nice __str__, and ET object have a lousy __str__. The objects can be extended, though, if we want to improve some of these things. > * Do you use the 'hinclude', 'htmlgen', 'textile', or > 'compress_resources' helpers? compress_resources is a distutils extension, not a helper. Different scope. > * There are three text-to-HTML helpers: 'htmlgen', 'textile', > 'markdown'. Do we need all of these or can we standardize on one? Do > they even need to be in WebHelpers at all? The user could import them > separately. On criteria might be if they wrap the respective libraries well (especially textile and markdown), if they expose enough, and if they have real value over the underlying libraries (e.g., a unified interface). > * 'simple_format' in 'webhelpers.rails.text' does your basic "text > paragraphs to <p> and single newlines to <br>" formatting. But > displaying untrusted text requires more formatting than this, > especially escapling/removing disallowed tags. Should we replace > 'simple_formatting' with something more sophistocated, and if so, > what? lxml.html.clean does cleaning. And it's fairly complicated (though the tests could be reused elsewhere). lxml is relatively harder to install than other pure-python libraries (harder than a simple C extension too as it uses a library, libxml2, usually provided by the system. And because Macs are annoying.) In theory translating stuff from lxml to ET wouldn't be that hard, except that's just the theory. This particular code makes use of XPath quite a bit, and the parent pointer that lxml has and ET does not. I think it's a really handy thing to have around, but it's just not easy. Maybe translating to BeautifulSoup would be easier. Or maybe we can figure out a way to make lxml eggs that are more reliable (e.g., statically compiled). > 'url_for' will likely be changing to a smarter 'url' object, and moved > out of WebHelpers. More info soon. After doing an application example with WebOb I've found the various *url properties on requests a bit annoying. I don't plan to get rid of them, but it would be nice if there was also a richer url object that encompassed more general URL manipulation. This won't be the same as url_for, which is tied to Routes, but ideally it would have some API overlap. I haven't really thought about what it would look like. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
