[Webkit-unassigned] [Bug 10750] New: SVG needs SVGAnimatedTypeNamePropertyName<ClassName> classes

[bugzilla-daemon at opendarwin.org]

http://bugzilla.opendarwin.org/show_bug.cgi?id=10750

           Summary: SVG needs SVGAnimatedTypeNamePropertyName<ClassName>
                    classes
           Product: WebKit
           Version: 420+ (nightly)
          Platform: Macintosh
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P4
         Component: SVG
        AssignedTo: webkit-unassigned at opendarwin.org
        ReportedBy: macdome at opendarwin.org


SVG needs SVGAnimatedTypeNamePropertyName<ClassName> classes

WildFox and Maciej and I have talked about this before, I'm just now putting it
down in the bug system for wider viewing:

In order to finally make the various SVGAnimated* types work again from the
javascript bindings we will need to create a set of new classes to function as
"tear-offs" from DOM objects, and to allow for proper integration with the
exiting auto-bindings system.  The system of classes we have designed for these
SVGAnimated* tear-off is as follows:

1.  Abstract base-classes for each of various SVGAnimated types. 
(SVGAnimatedBoolean, SVGAnimatedString, etc).  These could be created based
from a SVGAnimatedTemplate<T> similar to what we had with the old animation
system.
2.  Per-property, per-class SVGAnimatedType subclass for each of the
SVGAnimated* properties which we support.  A macro can be used to generate each
of these.  They should be in the form
SVGAnimatedTypeNamePropertyName<ElementClassName>.
3.  Extend the existing ANIMATED_PROPERTY macros to generate
animatedPropertyName() functions to create and return the SVGAnimated* tear-off
classes.
4.  Then we can just turn on all of the SVGAnimated*.idl files and viola!
bindings should "just work"

These various SVGAnimatedTypeNamePropertyName classes will look something like
this:

template<TypeName>
class SVGAnimatedTemplate<TypeName> : public
RefPtr<SVGAnimatedTemplate<TypeName> > {
public:
    virtual TypeName baseVal() = 0;
    virtual setBaseVal(TypeName) = 0;
    virtual TypeName animVal() = 0;
    virtual setAnimVal(TypeName) = 0;
protected:
    RefPtr<SVGElement> m_element;
};

template <ClassName>
class SVGAnimatedTypeNamePropertyName<ClassName> : public
SVGAnimatedTemplate<TypeName>  {
public:
    SVGAnimatedTypeNamePropertyName(SVGElement*);
    virtual ~ SVGAnimatedTypeNamePropertyName();
    virtual TypeName baseVal()
    {
            return
(static_cast<ClassName*>(m_element)->propertyNameBaseValue();
    }
    virtual void setBaseVal(TypeName newBaseVal, ExceptionCode&) // EC may be
optional, depending
    {
          
static_cast<ClassName*>(m_element)->setPropertyNameBaseVal(newBaseVal);
    }
    virtual TypeName animVal()
    {
            return static_cast<ClassName*>(m_element)->propertyName();
    }
    virtual void setAnimVal(TypeName newAnimVal, ExceptionCode&) // EC may be
optional, depending
    {
           static_cast<ClassName*>(m_element)->setPropertyName(newAnimVal);
    }
};

That should be about it.  This shouldn't take WildFox (or anyone else familiar
with the JS system and templates) more than a few hours of work.  Turning on
all of the SVGAnimated*.idl files can always be done at a later time.  However
once this is complete, turning them all on should be possible.

We can either use a single manually-generated SVGAnimatedTypes.h file (which
uses some Macros to write all these classes), or someone could write a little
perl script to crawl the IDLs and generate these for us.  I'm not sure which
would be cleaner.


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.