funformkit-discuss

[FunFormKit-discuss] extraHTML

[Luke O. <lu...@me...>]

If anyone's interested, I've made modifications to FFK to support the
extraHTML argument from FFK 0.3, for adding attributes within an HTML
tag (we use it for javascript events and CSS classes primarily, for
instance).

This was done with a change to SimpleHTMLGen.Tag to support
'extraHTML' as a special argument (full python below), and then
adding 'extraHTML=self._extraHTMLCode(options)' to the html.input( )
blocks if appropriate. (_extraHTMLCode utility method was already
written by Ian, but not used anywhere, due to the mismatch between
arbitrary attribs and the HTMLGen system, I assume.)

I'm not sure I'm entirely happy with the result, it removes some of
the cleanliness of the HTMLGen process, and users can screw
themselves by putting already-used attrs in extraHTML, but that's how
it's always been. :)

Enjoy,

- Luke

------
SimpleHTMLGen.py:

def Tag(tag, *args, **kw):
    if kw.has_key("c"):
        assert not args, "The special 'c' keyword argument cannot be
used in conjunction with non-keyword arguments"
        args = kw["c"]
        del kw["c"]
        if type(args) not in (type(()), type([])):
            args = (args,)
    extraHTML = ''
    if kw.has_key("extraHTML"):
        extraHTML = " %s" % kw["extraHTML"]
        del kw["extraHTML"]
    htmlArgs = [' %s="%s"' % (attrEncode(attr), htmlEncode(value))
                for attr, value in kw.items()
                if value is not Exclude]
    if not args and emptyTags.has_key(tag):
        if blockTags.has_key(tag):
            return "<%s%s%s/>\n" % (tag, "".join(htmlArgs),extraHTML)
        else:
            return "<%s%s%s/>" % (tag, "".join(htmlArgs),extraHTML)
    else:
        if blockTags.has_key(tag):
            return "<%s%s%s>\n%s\n</%s>\n" % (
                tag,
                "".join(htmlArgs),
                extraHTML,
                "".join(map(str, args)),
                tag)
        else:
            return "<%s%s%s>%s</%s>" % (
                tag,
                "".join(htmlArgs),
                extraHTML,
                "".join(map(str, args)),
                tag)

Re: [FunFormKit-discuss] extraHTML

[Ian B. <ia...@co...>]

On Fri, 2003-05-09 at 14:22, Luke Opperman wrote:
> If anyone's interested, I've made modifications to FFK to support the
> extraHTML argument from FFK 0.3, for adding attributes within an HTML
> tag (we use it for javascript events and CSS classes primarily, for
> instance).

As I'm rethinking FFK (i.e., FormEncode), I've left out this hook (which
wasn't in FFK originally either).  So maybe I'll bring it up -- what
should this really do?

If it's for CSS classes and Javascript, then I think those hooks should
be added directly (i.e., a class_ attribute, and onClick, etc.,
attributes).  But maybe it's not practical to make that complete (OTOH,
at some point you're going to have to create your own widget).

The problem with extraHTML is also that it's not always clear where it
goes -- compound widgets don't have a clear location.

  Ian

Re: [FunFormKit-discuss] extraHTML

[Luke O. <lu...@me...>]

> As I'm rethinking FFK (i.e., FormEncode), I've left out this hook
> (which wasn't in FFK originally either).  So maybe I'll bring it up
> -- what should this really do?

Yes, I need to take a closer look at FormEncode, get more of a feel of
what's changing...

> If it's for CSS classes and Javascript, then I think those hooks
> should  be added directly (i.e., a class_ attribute, and onClick,
> etc., attributes).  But maybe it's not practical to make that
> complete (OTOH, at some point you're going to have to create your
> own widget).

I started doing this as I was trying to find an alternative to
extraHTML this morning. The problem was that we immediately
identified that there are a LOT of javascript eventhandler attrs, and
I didn't feel like typing that much into every field. :) And knew I
wouldn't be complete.

In general I tend to create new Field subclasses for most of these
needs, as opposed to external onChange js functions etc. But
sometimes it's easier, and I think it will always be relevant to want
to pass some arbitrary attributes that we can't predict now. Also, if
there's no arbitrary way to add attrs, making your own widget is
harder as well (if I make a SuperSelectField that does something
requiring javascript, but I can't reuse SelectField's htInput method
because I want to add a specialized attr, I end up duplicating that
code, and making my life harder).

We played around with a more constrained version of extraHTML,
extraAttrs = {'onChange': 'randomFunction()', 'class': 'myStyle'} ,
with the advantage that a field could easily check this for conflicts
with attrs that it needs, and it fit more neatly into the HTMLGen
idea. But other developers here found the syntax a little too
abstract when compared to the benefits.

I guess in general I don't want to promote the use of extraHTML, but
in enough cases we've found it to be useful "used at your own risk"
to implement a one-time workaround/addition for a basic fieldtype. As
a second choice, I'd take an extraAttrs option.

> The problem with extraHTML is also that it's not always clear where
> it goes -- compound widgets don't have a clear location.

Completely agree. I left it off of these (like DateField,
TextareaFileUpload, etc), precisely because it's not clear. And
extraAttrs doesn't solve this. I'm undecided on whether these
specialized widgets affect my feelings about extraHTML, though. Hmm.

- Luke