Currently we use JSHTMLElementWrapperFactory and JSSVGElementWrapper factory when converting from impl pointers to the actual JS* binding classes. These are currently manually edited files, but they should be autogenerated. It should not be hard to modify ksvg2/scripts/make_names.pl to generate this sort of file as well. Once all of our bindings are autogenerated, it would be simple to use htmltags.in and svgtags.in as source data for these files. It would also be possible to use exiting logic in WebCore/bindings/scripts/CodeGenerator.pm to crawl through all .idl files to find all classes. Another way to work this would be to unify JS*ElementWrapperFactory files into a single hash lookup. That could be autogenerated.
Yeah, this needs to be fixed. These files are already out of date.
Eventually we'll fix this. It's just an hour or so of tweaking the perl scripts.
Created attachment 21207 [details] First try
Comment on attachment 21207 [details] First try Wow. Totally awesome. I assume you've diff'd the generated file from the old manual file to confirm that there are no bad changes? I think long term we want to move away from hacks in the perl file, and instead use a more advanced data file for generation. For example, you could encode all of the information from the perl hashes in the htmltags.in file using proper comments. (Or we could turn things like htmltags.in into XML like mozilla has for their bindings stuff.)
(In reply to comment #4) > (From update of attachment 21207 [details] [edit]) > Wow. Totally awesome. > > I assume you've diff'd the generated file from the old manual file to confirm > that there are no bad changes? Yes (it is not exactly a diff as the old code is using some macros to generate the code). The preparatory work I checked in last week was to guarantee that all tags would be guarded by the right #ifdefine guard and are not taken into account if the guard is not matched. I have also tested the build thoroughly with different options to confirm that I had not forgotten some generated code. > I think long term we want to move away from hacks in the perl file, and instead > use a more advanced data file for generation. For example, you could encode > all of the information from the perl hashes in the htmltags.in file using > proper comments. (Or we could turn things like htmltags.in into XML like > mozilla has for their bindings stuff.) I think the best way here is to opt for XML files. Some of make_names.pl parameters could also be included (like guardCppWith...) in the *.in files. It would also clean and simplify make_names.pl.
Committed in r34034. Submitted bug 19200 about the information that should be moved to the *.in files.