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