@Rick - I double checked with a few other folks today, and there is nothing
that precludes the proposal of auto-generating a constructor that is put in
scope before the script tag executes:
<element tagname="x-foo" inherits="SVGElement">
> <template>...</template>
> <script>
> XFooElement.prototype.bar = function(){...}
> XFooElement.prototype.readyCallback = function(){...}
> </script></element>
> </element>
>
> Where am I going wrong here?
>
> *>>> *This is not an issue --> *ReferenceError: XFooElement is not
> defined *
>
Given the parent <element> is parsed before the script tag is hit, there's
no reason a constructor object can't be created an put in scope before the
script tag is evaluated.
On Fri, Apr 12, 2013 at 7:53 PM, John J Barton
<johnjbarton@johnjbarton.com>wrote:
> I think Allen's post further down lays out my case better than I did, so
> I'm just trying to clean up.
>
>
> On Fri, Apr 12, 2013 at 3:31 PM, Dimitri Glazkov <dglazkov@google.com>wrote:
>
>> On Fri, Apr 12, 2013 at 2:06 PM, John J Barton
>> <johnjbarton@johnjbarton.com> wrote:
>>
>> >> The way <element> should work is like this:
>> >> a) when </element> is seen
>> >> b) generate a constructor for this element
>> >
>> >
>> > b) call the nominated ctor, new FooBar(elt).
>> >
>> > I'm unclear on the practical advantages the instance inheriting from
>> > HTMLElement (new FooBar(), prototype inherits) vs manipulating the
>> element
>> > from the outside (new FooBar(elt), prototype Object).
>>
>> I completely didn't get that, but it sounds like a slightly different
>> topic?
>>
>
> Perhaps; I'll try another thread.
>
>
>>
>> >> b) run document.register
>> >> c) run initialization code
>> >>
>> >> As I see it, the problem is twofold:
>> >>
>> >> 1) The <script> element timing is weird. Since <script> is
>> >> initialization code, it has to run after the </element> is seen. This
>> >> is already contrary to a typical <script> element expectations.
>> >
>> >
>> > Why? new FooBar() has to be called, but the outer init is anytime before
>> > that.
>>
>> We're not calling new FooBar anywhere in here. All the <element> does
>> is registers a custom element with the parser and blesses it to be a
>> real DOM object.
>>
>
> See Allen's post.
>
>>
>> >> 2) The <script> element needs a way to refer to the custom element
>> >> prototype it is initializing. Enclosing it in a function and calling
>> >> it with <element> as |this| seemed like a simplest thing to do, but
>> >> Rick and John had allergic reactions and had to be hospitalized.
>> >
>> >
>> > For me its the implicit declarative binding + wired in to 'this' that
>> makes
>> > the
>> > original solution very magical and inflexible. I can understand ensuring
>> > that
>> > a component can be self-contained, but cannot understand why it needs an
>> > ordered and hierarchical when <script> isn't rendered.
>>
>> The |this| hack was just a way to solve the problem of connecting
>> <element> and <script> somehow. I am not sure understand what you're
>> saying (suggesting?) here, either :)
>>
>
> I'm saying 1) I don't like the hack, 2) I appreciate that entirely
> conventional solutions will not solve all your issues.
>
>
>>
>> :DG<
>>
>
>