[webkit-dev] Proposal and ideas for a new .in format

[Julien Chaffraix]

[Forgot to CC the list]

On Thu, Jun 19, 2008 at 4:30 PM, Julien Chaffraix
<julien.chaffraix at gmail.com> wrote:
> On Thu, Jun 19, 2008 at 9:32 AM, Maciej Stachowiak <mjs at apple.com> 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
>