You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2009/09/26 20:35:37 UTC
WTKX scripting changes
Hi all,
Just a heads up that I have reverted a couple of my earlier changes to
scripting in WTKX:
1) A <wtkx:script> block is again required in element-based listener
lists. I had previously eliminated this requirement, thinking that it
was redundant. However, in doing so, I inadvertently created an
inconsistency with some other aspects of WTKX. Listener list elements
refer to a read-only property that returns a listener list. This is
conceptually similar to read-only properties that refer to sequences.
In WTKX, each sub-element of a read-only sequence element is added to
the sequence. Similarly, each sub-element of a listener list should
also be added to the listener list. Eliminating the need for a nested
<wtkx:script> tag broke this parity. Re-introducing the tag restores
the parity by ensuring that listener list elements will have sub-
elements (each of which is akin to an anonymous inner class instance
created in Java).
Coincidentally, this approach is also more consistent with HTML, which
apparently supports a similar syntax (though I was unaware of it until
this morning):
http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3
2) The scripting language used by the page is again specified within
the page itself, not to the WTKXSerializer used to load the page. I
realize that there isn't a strong use case for this "feature", but
HTML also works this way, so there is precedent for it. The
<wtkx:script> tag again supports a "language" attribute, and callers
can define the default script language used in a page using an XML
processing instruction as follows (HTML uses a <meta> tag for this,
but WTKX doesn't have a concept of meta tags):
<?language javascript?>
This PI can be placed anywhere in a script. It can even be used
multiple times, each time redefining the default scripting language
for the remainder of the page. However, I imagine that it will most
commonly be placed once (if at all) at the top of a script.
Again, apologies for the additional API thrashing, but I think we're
good now. As always, please let me know if you have any questions.
Greg
Re: WTKX scripting changes
Posted by Greg Brown <gk...@mac.com>.
Note that this change does not revert the new support for attribute-
based event handlers. Attribute-based event handlers are still
supported, and their syntax has not changed.
On Sep 26, 2009, at 2:35 PM, Greg Brown wrote:
> Hi all,
>
> Just a heads up that I have reverted a couple of my earlier changes
> to scripting in WTKX:
>
> 1) A <wtkx:script> block is again required in element-based listener
> lists. I had previously eliminated this requirement, thinking that
> it was redundant. However, in doing so, I inadvertently created an
> inconsistency with some other aspects of WTKX. Listener list
> elements refer to a read-only property that returns a listener list.
> This is conceptually similar to read-only properties that refer to
> sequences. In WTKX, each sub-element of a read-only sequence element
> is added to the sequence. Similarly, each sub-element of a listener
> list should also be added to the listener list. Eliminating the need
> for a nested <wtkx:script> tag broke this parity. Re-introducing the
> tag restores the parity by ensuring that listener list elements will
> have sub-elements (each of which is akin to an anonymous inner class
> instance created in Java).
>
> Coincidentally, this approach is also more consistent with HTML,
> which apparently supports a similar syntax (though I was unaware of
> it until this morning):
>
> http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3
>
> 2) The scripting language used by the page is again specified within
> the page itself, not to the WTKXSerializer used to load the page. I
> realize that there isn't a strong use case for this "feature", but
> HTML also works this way, so there is precedent for it. The
> <wtkx:script> tag again supports a "language" attribute, and callers
> can define the default script language used in a page using an XML
> processing instruction as follows (HTML uses a <meta> tag for this,
> but WTKX doesn't have a concept of meta tags):
>
> <?language javascript?>
>
> This PI can be placed anywhere in a script. It can even be used
> multiple times, each time redefining the default scripting language
> for the remainder of the page. However, I imagine that it will most
> commonly be placed once (if at all) at the top of a script.
>
> Again, apologies for the additional API thrashing, but I think we're
> good now. As always, please let me know if you have any questions.
>
> Greg
>
Re: WTKX scripting changes
Posted by Greg Brown <gk...@mac.com>.
Note that this change does not revert the new support for attribute-
based event handlers. Attribute-based event handlers are still
supported, and their syntax has not changed.
On Sep 26, 2009, at 2:35 PM, Greg Brown wrote:
> Hi all,
>
> Just a heads up that I have reverted a couple of my earlier changes
> to scripting in WTKX:
>
> 1) A <wtkx:script> block is again required in element-based listener
> lists. I had previously eliminated this requirement, thinking that
> it was redundant. However, in doing so, I inadvertently created an
> inconsistency with some other aspects of WTKX. Listener list
> elements refer to a read-only property that returns a listener list.
> This is conceptually similar to read-only properties that refer to
> sequences. In WTKX, each sub-element of a read-only sequence element
> is added to the sequence. Similarly, each sub-element of a listener
> list should also be added to the listener list. Eliminating the need
> for a nested <wtkx:script> tag broke this parity. Re-introducing the
> tag restores the parity by ensuring that listener list elements will
> have sub-elements (each of which is akin to an anonymous inner class
> instance created in Java).
>
> Coincidentally, this approach is also more consistent with HTML,
> which apparently supports a similar syntax (though I was unaware of
> it until this morning):
>
> http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3
>
> 2) The scripting language used by the page is again specified within
> the page itself, not to the WTKXSerializer used to load the page. I
> realize that there isn't a strong use case for this "feature", but
> HTML also works this way, so there is precedent for it. The
> <wtkx:script> tag again supports a "language" attribute, and callers
> can define the default script language used in a page using an XML
> processing instruction as follows (HTML uses a <meta> tag for this,
> but WTKX doesn't have a concept of meta tags):
>
> <?language javascript?>
>
> This PI can be placed anywhere in a script. It can even be used
> multiple times, each time redefining the default scripting language
> for the remainder of the page. However, I imagine that it will most
> commonly be placed once (if at all) at the top of a script.
>
> Again, apologies for the additional API thrashing, but I think we're
> good now. As always, please let me know if you have any questions.
>
> Greg
>