On 11/2/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
> Kevin Dangoor wrote:
> > What I'm thinking of is allowing each widget to specify some
> > JavaScript and CSS that it needs to have. If you're planning to
> > distribute your widget to others (or even just generally), you should
> > use fully qualified names (like MochiKit does) to avoid naming
> > collisions. Name mangling is cool, but I don't think I want to tackle
> > that now.
>
> That breaks the relation between server-side code and browser-side code.
> I like my browser to use names, filenames, and line numbers I
> recognize. And Javascript isn't really *that* bad for building
> abstractions; there's no need for code generation. So that's just my
> vote for never, not later, on the name mangling.
I agree that JavaScript isn't that bad. I'd imagine it's possible to
make name mangling that's still readable, but my #1 concern is name
mangling that breaks the code (or telling people "don't do it that
way, because that won't work with the mangler... write your code this
way...").
> > If you use multiple of the same widget on a page, the JavaScript would
> > appear once. I also want to make it possible for several widgets to
> > share one JavaScript file (which reduces page size and saves server
> > roundtrips when there are multiple scripts).
> >
> > There are three things that I'm working on before I go into the level
> > of detail with widgets that I did with the forms:
> >
> > 1) JavaScript/CSS inclusion
>
> I think it would be good to lean on Javascript more than might
> immediately seem necessary; i.e., to build a Javascript framework for
> forms intead of generating too much ad hoc Javascript for the widgets.
>
> So, for instance, WHAT-WG Web Forms 2.0 defines a bunch of new form
> controls. Those are a nice place to start -- in many cases some
> Javascript is all that's needed to implemented those HTML extensions,
> and the a date input widget can just generate '<input type="date">'. In
> other cases you can use Kids' matching, potentially, to transform that
> HTML to something browsers like more -- but that shouldn't be necessary.
I'm envisioning JavaScript being used for things like "yellow fade"
and drag and drop, and not just basic controls functions. While
TurboGears will likely come with a standard JavaScript library that
includes functions used by the whole set of widgets, I still want it
to be possible to just drop in an egg of other widgets that have their
own JavaScript that they use.
> Another thing I've thought about that's a little simpler is something
> like 'mochi-onload="some_func"', and when the document was loaded all
> the elements would be inspected for that attribute, when found doing
> something like:
>
> eval(el.getAttribute('mochi-onload')).apply(el)
>
> This is a low-impact way of attaching functionality, without getting too
> terribly fancy.
That does seem like a good way to deal with each widget potentially
having its own "onload" functionality.
Kevin
