Hello,
I am working on a custom component library and have observed some
unexpected behavior regarding attribute namespace prefix usage. Can
someone please clarify the official Tapestry rules regarding the usage
of component attribute namespace prefixes? Here are two scenarios that I
believe get to the crux of the question:
1) Component id attributes (t:id="..." v.s. id="...")
I have been happily using t:id="...." in my templates, but found that
Tapestry will not accept values that are not valid Java identifiers.
This is very inconvenient since we are creating a wrapper for an ajax
widget set that uses hyphenated names. What I have found is that using
the "id" attribute without a prefix works:
This fails since "my-button" is not a valid Java identifier:
<t:kendo.Button t:id="my-button" . . . />
This succeeds (without the "t:" prefix) and works as expected.
<t:kendo.Button id="my-button" . . . />
For reference, our custom components implement the ClientElement
interface and use the JavaScriptSupport. allocateClientId(...) method to
get the client element Id from the template.
I have not yet traced into the Tapestry code, but it also appears that
"id" attribute values (without the t: prefix) are being mapped to
equivalent camel-case Java-compatible identifiers. This behavior makes
sense since the HTML 5 DOM reportedly uses a similar attribute mapping
scheme:
http://stackoverflow.com/questions/20985204/does-jquery-internaly-converts-html5-data-attribute-keys-to-lowercase
2) Omitting the t: attribute prefix seems to work except for t:mixins=".
. ."
I have found through empirical evidence that I can omit the "t:"
attribute prefix when configuring custom components in templates. The
one exception seems to be t:mixins=". . .", which appears to be ignored
if the prefix is omitted:
This succeeds and applies the mixin to the component:
<t:kendo.Button t:mixins="kendo/deferShow" . . . />
This is accepted, but does not apply the mixin to the component:
<t:kendo.Button mixins="kendo/deferShow" . . . />
Is the ability to omit the namespace prefix an intentional feature, or a
side effect of the way templates are being parsed?
I am unclear on the expected Tapestry behavior. My original
understanding was that attributes matching declared component properties
would behave the way the mixins attribute is working. Being able to omit
the prefix is nice, but I don't want to depend on a feature that is not
officially supported.
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
