Hi Cezary,
Thanks for the clarification. I was aware of the problem with id and
name values related to loops and forms, but did not have a detailed
picture as to how Tapestry uses "id" and "t:id" in that scenario. The
same applies to the "name" attribute handling, but we have not yet had a
need to open that can of worms.
As an aside, the context of my question is related to work we are doing
to create a hybrid Tapestry / SPA architecture. Getting the two
paradigms to integrate seamlessly has been an interesting and
challenging adventure. Hopefully, Tapestry will be moving more that
direction in the future since client-side technologies are evolving
rapidly and here to stay.
Thanks,
David
emailsig On 11/23/2015 3:00 PM, Cezary Biernacki wrote:
Hi David,
Regarding your point 1). "t:id" is quite different than "id". "t:id" is
used to map component definitions in templates to component injections in
Java classes. "id" (without namespace) is HTML "id" attribute, and while
often Tapestry generates "id" that is equal to "t:id", it is not always
true (IIRC, e.g. when component is used multiple times on the page, or when
response is generated for Ajax request). Another difference is that "t:id"
must be also constant, while "id" can be dynamically generated.
Use "t:id" when you want to refer to your components in Java code (plus
from some other components, e.g. in Label's "for" attribute). Use "id" when
you want to force some particular "id" value in the generated HTML, but
watch for cases when it is component that might be included multiple times
on a page, in loops or in AJAX responses.
Best regards,
Cezary
On Mon, Nov 23, 2015 at 7:51 PM, David Taylor <david.tay...@extensiatech.com
wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
