Basic HTML helpers
Mike Orr
complete HTML document. What do you guys think of the API and
semantics?
http://bitbucket.org/bbangert/webhelpers/issue/13/doctype-helper
http://bitbucket.org/bbangert/webhelpers/issue/14/simple-html-template-helper
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)
--
Mike Orr <slugg...@gmail.com>
jgar...@jonathangardner.net
> 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.
> 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.
> 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
Mike Orr
On Wed, Jan 13, 2010 at 12:31 PM, jgar...@jonathangardner.net
<jgar...@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):
===
--
Mike Orr <slugg...@gmail.com>
James Gardner
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