[Forgot to CC the list]
On Thu, Jun 19, 2008 at 4:30 PM, Julien Chaffraix <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 9:32 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >> >> On Jun 19, 2008, at 12:56 AM, Eric Seidel wrote: >> >>> Not a big fan of using the negative: >>> >>> noWrapperFactory=1 >>> >>> Should be something like: >>> includeInWrapperFactory=0 >> >> Why would anything be excluded from the wrapper factory in the first place? >> Are those just elements where the wrapper is JSHTMLElement and not some more >> specific class? In which case, I think it is ok to just specify that as the >> interface name. > > Those elements do not have a specific wrapper and returns a new > JSHTMLElement (the wrapper are just a way of choosing which class to > use). > Using the interface name would not work IMHO: take for example the > animateMotion tag in svgtags.in, it has an entry in > SVGElementFactory.cpp as it has his own class but uses the default > JSSVGElement in SVGElementWrapperFactory. > > I am not sure what is the rationale behind this difference. A > work-around would be to have another attribute that we could set to > HTMLElement and only to use for the JS*ElementWrapperFactory (this is > what is achieved with the current hasCustomMapping method and the idea > behind customWrapper and noWrapperFactory). > >> >>>> >>>>> I'm not sure what the audio hack is. >>>> >>>> Audio tags need a special wrapper so the attribute triggers generating >>>> it. Maybe "isAudioTag" would be more explicit? >> >> OK, so the audio special case seems to be if (!MediaPlayer::isAvailable()), >> make a generic HTMLElement instead. The first thing I wonder is whether this >> should apply to video as well as audio. If so, maybe the parameter should be >> something like wrapperOnlyIfMediaIsAvailable=1. >> >> Another thought: is there any case where we want the C++ namespace to be >> anything but WebCore? I think not, in which case we should probably hardcode >> this in the script instead of making it a parameter. > > When dealing with the different files, I have not seen anything but > WebCore. I will not change that with XBL2 so it could be removed if no > one has an objection. > >> >> >>>> >>>> >>>>> Instead of "upperCase", might it make sense to call that "interfaceName" >>>>> for >>>>> cases where the interface is not the obvious thing derived from the tag >>>>> name? "Anchor" isn't really an uppercase version of "a", and for h1-h6 >>>>> all >>>>> of them would have Header in the interface name, but it's not really an >>>>> uppercase version. Might it make sense to even say >>>>> interface=HTMLAnchorElement? >>>> >>>> upperCase usually really represents the upper case (Camel-case) name >>>> but there is some exceptions. >>>> I am fine with "interface" or "interfaceName" but you could not write >>>> interface=HTMLAnchorElement as the "interface" value has other use >>>> that just the class name (wrapper function name, QualifiedName, ...). >>>> Maybe "useCustomInterface" would be an even better name as there is a >>>> default value? >> >> The wrapper function name could use the full interface name IMO, or else the >> tag name like the defined QName does. The QualifiedName is based on the >> actual tag name, isn't it? > > I checked and you are right. > >> It's HTMLNames::aTag, not anchorTag. What else >> uses the uppercase version of the name? > > The #include lines also uses the uppercase version but it would not > bother to use the full interface name there too. > > All in all, I think your suggestion could work (requiring a small > cleanup of make_names.pl). Remains the JS*ElementWrapperFactory issue > I raised above. > > Regards, > > Julien > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
