On Jan 8, 2008 12:21 PM, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> 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.
I remember another XML serializer that was more pythonic than
ElementTree, though I can't remember which one it was.
> > * '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).
I don't want to add anything that depends on C libraries. That just
makes things a hassle to install (Windows doesn't come with a
compiler; Mac puts things in nonstandard locations). Which makes a
percentage of users choose something else instead.
> > '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.
url_for could be implemented on top of something. Of course there's
always the need to parse and assemble URLs, which can be put in a
class. What we're considering is an object with route-generation
methods:
url_for.home() # A named route.
url_for.blog(id=1234) # Another named route.
url_for(controller="foo", action="dig")
# Use the default route (:controller/:action/:id)
url_for.current(page=2) # Derive a URL from the current page.
url_for.current("faq/") # Possibly a urljoin from the current page.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
