Just in case it is causing confusion it was Jonathan who responded rather than me. We are both J. Gardner but I'll still be posting as James Gardner from ja...@pythonweb.org.
Jonathan, perhaps you could change your subscription settings to use your name as the name that gets displayed rather than your email address to help avoid further confusion? Cheers, James , On Wed, 2010-01-13 at 13:19 -0800, Mike Orr wrote: > Thanks for your feedback, James. > > On Wed, Jan 13, 2010 at 12:31 PM, jgard...@jonathangardner.net > <jgard...@jonathangardner.net> wrote: > > On Dec 16 2009, 8:43 pm, Mike Orr <sluggos...@gmail.com> wrote: > >> A couple proposed helpers, one for doctypes and one to generate a > >> complete HTML document. What do you guys think of the API and > >> semantics? > >> > >> http://bitbucket.org/bbangert/webhelpers/issue/13/doctype-helper > >> > > > > I like. > > It's in beta 3, webhelpers.html.tags.Doctype class and > xml_declaration() function. > > >> Also, I can't find a simple function to generate a URL with query > >> string (not using Routes). Is there an equivalent to this somewhere > >> I've overlooked? > >> > >> def url(urlpath, **params): > >> if not params: > >> return urlpath > >> return urlpath + "?" + urllib.urlencode(params) > >> > > > > http://docs.python.org/library/urlparse.html#urlparse.urlunparse > > Beta 3 has webhelpers.util.update_params() in webhelpers.util. I may > move it to a new webhelpers.urls module though. > > Urlparse returns the entire query as a string, and urlunparse expects > it that way. That leaves the encoding to the client, who has to > remember which non-intuitively named function in which non-intuitively > named module does it, which I was trying to avoid. I also threw in the > ability to update individual parameters whether they exist or not, > which I've found useful sometimes. > > >> http://bitbucket.org/bbangert/webhelpers/issue/14/simple-html-templat... > >> > > > > If we're going this far, it might make more sense to construct the > > document with something akin to DOM and then output that. > > > > Kind of eliminates the need for something like Mako altogether now, > > doesn't it? I'm not complaining, since I've found programming the HTML > > page is easier than writing out the HTML code itself. > > There's some code in WebHelpers/unfinished/document.py . I was > planning to use the HTML builder, which is not a DOM but is pythonic. > Is there a suitable DOM in the stdlib? Besides ElementTree, which is > specifically for XML. webhelpers.feedgenerator does use > xml.sax.saxutils.XMLGenerator already, although I don't like how it > doesn't put newlines after tags, so the entire document comes out as > one long line without whitespace. (I've been meaning to see if I can > update feedgenerator for that.) > > The document helper would mainly be for simple applications that don't > need a full template dependency. Like webhelpers.html.grid_demo, > which is what gave me the idea in the first place. Line 168: > > # XXX There should be helpers to create a basic HTML file. > > It punts the "%" operator in the meantime. > > I'm not sure if the document helper will make it into 1.0 because the > documentation work is higher priority and I want to make a final > release soon. > > Mako would still be needed for something like a Pylons form. Although > you could use the document helper to apply the site "template" around > the page. That could be done in a custom render() function, I guess. > But my site templates are pretty complex, so I don't plan to use the > document helper for them. > > One issue I'm wondering is how much to accommodate temporary (X)HTML > conventions, given that HTML 5 will be usable as soon as people switch > to capable browsers. My reading of the recommendations is that you > need redundant 'lang' and 'xml:lang' attributes, and some people even > put two types of <meta> tags for the charset (with http-equiv and > without). > > <html xmlns="http://www.w3.org/1999/xhtml"; xml:lang="en" lang="en"> > <head> > <title>%(title)s</title> > <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> > <link rel="stylesheet" type="text/css" href="demo.css" /> > </head> > > Is it worth doing all this? I do want to support the universal head > features (title, charset, lang) without forcing users to pass a > supplemental head string. The signature is currently: > > === > class HTMLDocument(object): > def __init__(self, body, head=None, doctype=None, > html_attrs=None, head_attrs=None, body_attrs=None, > encoding=None, lang=None, title=None, xml_version="1.0"): > > # Return finished document in specified format as string. > def html5(self): > def html5_xml(self): > def xhtml1(self): > def html4(self): > === >
-- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
