Make it possible for sky-element to register any tag name

Make it possible for sky-element to register any tag name

... instead of hard-coding "example".

We do this by adding a custom constructor for Element that gets the |tagName|
property off the instance.

R=esprehn@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/c90a467537ffe2e02c59fa0f577e241f6ff6a2a9

[esprehn, 2015-02-21 07:44:47]

esprehn@chromium.org changed reviewers:
+ esprehn@chromium.org

[esprehn, 2015-02-21 07:44:47]

We should discuss this change in person.

[abarth-chromium, 2015-02-21 07:51:40]

IMHO, it's worth landing this change in order to make progress bringing up the
custom element framework.  If we decide to go with a different design, we can
change how this works by change the engine and SkyElement.  Without something
like this CL, the custom element framework is blocked because we can only
register elements named "example".  :)

[esprehn, 2015-02-21 09:58:16]

On 2015/02/21 at 07:51:40, abarth wrote:
> IMHO, it's worth landing this change in order to make progress bringing up the
custom element framework.  If we decide to go with a different design, we can
change how this works by change the engine and SkyElement.  Without something
like this CL, the custom element framework is blocked because we can only
register elements named "example".  :)

We could implement registerElement instead?

[esprehn, 2015-02-21 09:58:27]

lgtm

[abarth-chromium, 2015-02-21 15:53:25]

On 2015/02/21 at 09:58:16, esprehn wrote:
> We could implement registerElement instead?

We do implement registerElement.  The two mechanism solve different problems. 
It'll be much easier to explain with a whiteboard, but I'll give it a try here.

1) In Sky, you can now subclass any host class that has a constructor. 
Subclassing works just the way it normally does in Dart.  For example, you can
create a class MyEvent that extends Event and you can use MyEvent everywhere
that Event can be used, including dispatchEvent.  This is different from the web
platform where host objects are weird and can't be subclassed.

2) As an example of (1), you can create a MyText class that subclasses Text
(because Text is constructible) and use instances of MyText anywhere you could
use instances of Text.

3) For custom elements, we want authors to be able to subclass Element.  The
most natural way to make that work is to give Element a constructor.

4) Now, suppose you create a MyElement class that subclasses Element and you
create an instance |foo| of MyElement.  What should |foo.tagName| return? 
Notice that in the web platform this isn't possible because the only way to get
an instance of MyElement would be to use the document.createElement factory (or
the fake constructor we return from registerElement).  There are at least two
possibilities:

  a) We could disallow this situation by throwing if you haven't called
registerElement to associate a tag name with MyElement.  Subclassing elements
would then work differently than subclassing Event and Text, neither of which
require any registration.  (For Event, the Event constructor takes a |type|
parameter, which lets subclasses determine their type by passing arguments to
their superclass constructor, just like we do internally in the engine.)

  b) We could somehow determine at construction time what the tagName ought to
be.  In this CL, we do that by reading the |tagName| property of the object
inside the superclass constructor.  (Note: It's a normal in Dart to call virtual
functions in base class constructors.  Unlike in C++, you get to call the
most-derived version of the virtual function.)

Essentially, we've answered the question of "what should |foo.tagName| return?"
by saying "it should return the value of the |tagName| property of |foo| at
construction time."

Separately, you can call registerElement to teach the parser (and the
document.createElement factory) about your subclass of Element.  Notice that
there isn't a one-to-one mapping between registered tagNames and classes because
each module has a separate element registry.  Even if we forced all element
creation to go through the document.createElement factory, you can end up with
an element tree that has two elements with the same tagName but different
runtimeTypes.  (Note: This is true on the web as well.)

I'm not claiming the approach in this CL is the best approach.  We should
discuss it in more detail when you're back in the office.  What I'm saying is
that it's a complex problem and Ian and I tried several different approaches on
Friday and, of the ones we tried, the approach in this CL seemed to best balance
the various concerns.

[abarth-chromium, 2015-02-21 16:02:36]

Committed patchset #1 (id:1) manually as
c90a467537ffe2e02c59fa0f577e241f6ff6a2a9 (presubmit successful).