You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by David Taylor <da...@extensiatech.com> on 2015/11/23 19:51:22 UTC
Attribute namespace prefix usage
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Attribute namespace prefix usage
Posted by David Taylor <da...@extensiatech.com>.
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.taylor@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Attribute namespace prefix usage
Posted by Cezary Biernacki <ce...@gmail.com>.
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.taylor@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>