[Webkit-unassigned] [Bug 73156] [Microdata] Implement HTMLPropertiesCollection collection.namedItem()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=73156





--- Comment #17 from Kentaro Hara <haraken at chromium.org>  2012-02-27 03:29:53 PST ---
(From update of attachment 126761)
View in context: https://bugs.webkit.org/attachment.cgi?id=126761&action=review

>>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:2235
>>> +    if ($interfaceName eq "HTMLPropertiesCollection") {
>> 
>> Maybe you can remove the hard-coding by using [CustomNamedGetter] (or [JSCustomNamedGetter]). https://trac.webkit.org/wiki/WebKitIDL#CustomNamedGetter
> 
> To use [CustomNamedGetter] or [NamedGetter] we need to define JSPropertiesCollection::canGetItemsForName() and JSPropertiesCollection::nameGetter() in JSPropertiesCollectionCustom.cpp
> 
> Please check my previous patch https://bugs.webkit.org/attachment.cgi?id=124521&action=prettypatch. Here I have used [NamedGetter] and defined above functions in JSPropertiesCollection.cpp. Is this approach is correct?

Sorry, I was confused. You are doing the right thing.

The core problem would be that CodeGeneratorJS.pm does not yet implement non-custom named getters. Currently, no matter if it is [NamedGetter] or [CustomNamedGetter], we need to write custom bindings to WebCore/bindings/js/JS*Custom.cpp. And your patch is trying to avoid the custom bindings (only) for HTMLPropertiesCollection... right? In that case, hard-coding "HTMLPropertiesCollection" would make sense as a first step. (Eventually we should fix CodeGeneratorJS.pm so that it generates the bindings code automatically for [NamedGetter].)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.