You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jochen Frey <jo...@jochenfrey.com> on 2012/03/07 06:18:31 UTC
ComponentParameters - Binding Expressions - "component:"
Hi!
A general pattern for an Eventlink with an Ajax zone can look something like this:
X.java:
public class CTest {
@InjectComponent @Property private Zone aZone;
}
X.tml:
<t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<t:eventlink zone="prop:aZone.clientId"/>
<t:zone t:id="aZone"/>
</t:container>
Where in essence I use a @Property in Java to generate the correct clientId for the t:zone parameter to the eventlink.
I was wondering if there's a way to guarantee the correct clientID (not the t:id) without going through a Java @Property.
Looking at the documentation one might hope that something like this would work:
<t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<t:eventlink zone=
"component:aZone"
/>
<t:zone t:id="aZone"/>
</t:container>
But "component:aZone" doesn't get the ID (which I expected from the documentation here: Binding Expressions - component: http://tapestry.apache.org/component-parameters.html), but instead I gets the actual Zone Object (which is great for many other use cases).
And as far as I can tell, it's not possible to do something like this (see below) either:
"component:aZone.clientId"
Am I missing something, or is it simply a requirement to go through the java class?
Thanks so much!
Jochen
---
jochen@jochenfrey.com
+1.415.366.0450
@jochen_frey
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ComponentParameters - Binding Expressions - "component:"
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 07 Mar 2012 04:30:49 -0300, Paul Stanton <pa...@mapshed.com.au>
wrote:
> Why not just use:
>
> <t:container
> xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
> <t:eventlink zone="aZone"/>
> <t:zone t:id="aZone" id="aZone" />
> </t:container>
>
> ?
Yep! Most Tapestry components, including Zone, use the id which is
explicitly provided such as in the above example.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Jochen Frey <jo...@jochenfrey.com>.
I have considered @AfterRender (and tried it at some point), but I may have to revisit that since it's been a while and maybe I was missing something.
... and since you asked:
We are building components by tightly integrating .java, .tml, and .js, so that they can be re-used by non specialists. Due to our product requirements we typically have to heavily customize components, or roll our own integrations between Tapestry, client side JS, and JQuery (in addition to using and modifying available integrations and components, which are a great place start).
We are trying to stay within the TS framework as much as possible, which causes us to use "Zone" a lot, and that means dealing with the 't:id' vs 'id' issues since we often need to pass clientId's into our JavaScript integrations, and that in turn causes us to manage our own id's.
That and guessing at the custom events that Tapestry or tapestry-jquery may be using are the two sharp edges we've not been able to find satisfying solutions for.
That being said, Tapestry is a fantastic framework which I wouldn't want to miss, and it provides tons of value. What I am talking about above is what we are seeing when we are pushing the boundaries of Tapestry towards more customized client-side experiences, including ones that go way beyond BeanEditor and similar components.
Maybe this was a case of "too much information" ... but there you have it ;-)
J
On Mar 8, 2012, at 8:53 AM, Thiago H. de Paula Figueiredo wrote:
> On Thu, 08 Mar 2012 13:46:47 -0300, Jochen Frey <jo...@jochenfrey.com> wrote:
>
>> My real concern is slightly different. It boils down to the fact that it is incredibly hard (if not impossible in certain situations) to determine the automatically generated ClientID of a component (that's embedded in the current component) during @SetupRender.
>
> Have you tried it in @AfterRender?
>
>> Worst of all, it really slows down adoption (or acceptance) of Tapestry with JavaScript specialists.
>
> I guess they wouldn't use Zones anyway . . . or am I wrong? (often I am).
>
> Maybe this is a similar scenario to what we sometimes find with BeanEditForm/BeanEditor: they're meant to be used as scaffolding, giving nice results for more common scenarios, not meant to be used in heavy customization ones.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
---
jochen@jochenfrey.com
+1.415.366.0450
@jochen_frey
Re: ComponentParameters - Binding Expressions - "component:"
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Thu, 08 Mar 2012 13:46:47 -0300, Jochen Frey <jo...@jochenfrey.com>
wrote:
> My real concern is slightly different. It boils down to the fact that
> it is incredibly hard (if not impossible in certain situations) to
> determine the automatically generated ClientID of a component (that's
> embedded in the current component) during @SetupRender.
Have you tried it in @AfterRender?
> Worst of all, it really slows down adoption (or acceptance) of Tapestry
> with JavaScript specialists.
I guess they wouldn't use Zones anyway . . . or am I wrong? (often I am).
Maybe this is a similar scenario to what we sometimes find with
BeanEditForm/BeanEditor: they're meant to be used as scaffolding, giving
nice results for more common scenarios, not meant to be used in heavy
customization ones.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Jochen Frey <jo...@jochenfrey.com>.
My real concern is slightly different. It boils down to the fact that it is incredibly hard (if not impossible in certain situations) to determine the automatically generated ClientID of a component (that's embedded in the current component) during @SetupRender.
This forces developers to manage their own ids (as suggested by Paul and Thiago), and in my experience it's error prone and cumbersome.
Worst of all, it really slows down adoption (or acceptance) of Tapestry with JavaScript specialists.
J
On Mar 8, 2012, at 5:03 AM, Denis Stepanov wrote:
>> The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
>
> Again and again randomly generated zone id confuses developers. :)
>
> Should I collect all mail posts with that problem at my issue: "Warn user or disallow zone with randomly generated id"? :)
>
> https://issues.apache.org/jira/browse/TAP5-1834
>
> Denis
>
> Mar 7, 2012 v 7:09 PM, Jochen Frey:
>
>> That's definitely another way of solving this. Still goes by way of the java file, but provides a different sort of flexibility.
>>
>> Cheers!
>> J
>>
>> On Mar 7, 2012, at 9:30 AM, Thiago H. de Paula Figueiredo wrote:
>>
>>> On Wed, 07 Mar 2012 13:41:02 -0300, Jochen Frey <jo...@jochenfrey.com> wrote:
>>>
>>>> Thanks guys!
>>>
>>> Hi!
>>>
>>>> I have a lot of components that are re-used either in loops, or just embedded in multiple components (often in the same page).
>>>>
>>>> The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
>>>
>>> Again, provide the id yourself, in this case dinamically (id="${generatedId}"). When you don't provide the id yourself, Tapestry components generate a random one when it finds the original id, based in t:id, is already taken.
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
>>> Owner, Ars Machina Tecnologia da Informação Ltda.
>>> http://www.arsmachina.com.br
>>
>> ---
>> jochen@jochenfrey.com
>> +1.415.366.0450
>> @jochen_frey
>>
>
---
jochen@jochenfrey.com
+1.415.366.0450
@jochen_frey
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Denis Stepanov <de...@gmail.com>.
> The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
Again and again randomly generated zone id confuses developers. :)
Should I collect all mail posts with that problem at my issue: "Warn user or disallow zone with randomly generated id"? :)
https://issues.apache.org/jira/browse/TAP5-1834
Denis
Mar 7, 2012 v 7:09 PM, Jochen Frey:
> That's definitely another way of solving this. Still goes by way of the java file, but provides a different sort of flexibility.
>
> Cheers!
> J
>
> On Mar 7, 2012, at 9:30 AM, Thiago H. de Paula Figueiredo wrote:
>
>> On Wed, 07 Mar 2012 13:41:02 -0300, Jochen Frey <jo...@jochenfrey.com> wrote:
>>
>>> Thanks guys!
>>
>> Hi!
>>
>>> I have a lot of components that are re-used either in loops, or just embedded in multiple components (often in the same page).
>>>
>>> The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
>>
>> Again, provide the id yourself, in this case dinamically (id="${generatedId}"). When you don't provide the id yourself, Tapestry components generate a random one when it finds the original id, based in t:id, is already taken.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
>> Owner, Ars Machina Tecnologia da Informação Ltda.
>> http://www.arsmachina.com.br
>
> ---
> jochen@jochenfrey.com
> +1.415.366.0450
> @jochen_frey
>
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Jochen Frey <jo...@jochenfrey.com>.
That's definitely another way of solving this. Still goes by way of the java file, but provides a different sort of flexibility.
Cheers!
J
On Mar 7, 2012, at 9:30 AM, Thiago H. de Paula Figueiredo wrote:
> On Wed, 07 Mar 2012 13:41:02 -0300, Jochen Frey <jo...@jochenfrey.com> wrote:
>
>> Thanks guys!
>
> Hi!
>
>> I have a lot of components that are re-used either in loops, or just embedded in multiple components (often in the same page).
>>
>> The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
>
> Again, provide the id yourself, in this case dinamically (id="${generatedId}"). When you don't provide the id yourself, Tapestry components generate a random one when it finds the original id, based in t:id, is already taken.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
---
jochen@jochenfrey.com
+1.415.366.0450
@jochen_frey
Re: ComponentParameters - Binding Expressions - "component:"
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 07 Mar 2012 13:41:02 -0300, Jochen Frey <jo...@jochenfrey.com>
wrote:
> Thanks guys!
Hi!
> I have a lot of components that are re-used either in loops, or just
> embedded in multiple components (often in the same page).
>
> The pattern that Paul and Thiago are suggesting works fine if that
> component occurs a single time on a page. However, if you use it
> multiple times, the client side zoneId (as well as the Tapestry JS
> initializers) are not unique any more, which causes the same zone to be
> updated all the time, no matter which EventLink got the click.
Again, provide the id yourself, in this case dinamically
(id="${generatedId}"). When you don't provide the id yourself, Tapestry
components generate a random one when it finds the original id, based in
t:id, is already taken.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Jochen Frey <jo...@jochenfrey.com>.
Thanks guys!
I have a lot of components that are re-used either in loops, or just embedded in multiple components (often in the same page).
The pattern that Paul and Thiago are suggesting works fine if that component occurs a single time on a page. However, if you use it multiple times, the client side zoneId (as well as the Tapestry JS initializers) are not unique any more, which causes the same zone to be updated all the time, no matter which EventLink got the click.
Example
Page.tml:
<html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<t:component/>
<t:component/>
</html>
Component.tml:
<t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<t:eventlink t:id="link" zone="aZone">click me</t:eventlink>
<t:zone t:id="aZone" id="aZone"> ${counter} </t:zone>
</t:container>
In this case, no matter which link you click, the first component will get updated because the zone in the first and the 2nd have the same client side id.
Hence my looking around for a solution that would allow me to do this in .tml only as per my original mail. "component:" seemed to be a solution as per the documentation (see below), but doesn't do the trick.
In other words, it would be nice if there was a component binding that did the equivalent of this:
.java
@InjectComponent @Property Zone aZone;
.tml
"prop:aZone.clientId"
Cheers!
Jochen
On Mar 6, 2012, at 11:30 PM, Paul Stanton wrote:
> Why not just use:
>
> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
> <t:eventlink zone="aZone"/>
> <t:zone t:id="aZone" id="aZone" />
> </t:container>
>
> ?
>
> On 7/03/2012 4:18 PM, Jochen Frey wrote:
>> Hi!
>>
>> A general pattern for an Eventlink with an Ajax zone can look something like this:
>>
>> X.java:
>> public class CTest {
>> @InjectComponent @Property private Zone aZone;
>> }
>>
>> X.tml:
>> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
>> <t:eventlink zone="prop:aZone.clientId"/>
>> <t:zone t:id="aZone"/>
>> </t:container>
>>
>>
>> Where in essence I use a @Property in Java to generate the correct clientId for the t:zone parameter to the eventlink.
>>
>> I was wondering if there's a way to guarantee the correct clientID (not the t:id) without going through a Java @Property.
>>
>>
>> Looking at the documentation one might hope that something like this would work:
>>
>> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
>> <t:eventlink zone=
>> "component:aZone"
>> />
>> <t:zone t:id="aZone"/>
>> </t:container>
>>
>>
>> But "component:aZone" doesn't get the ID (which I expected from the documentation here: Binding Expressions - component: http://tapestry.apache.org/component-parameters.html), but instead I gets the actual Zone Object (which is great for many other use cases).
>>
>> And as far as I can tell, it's not possible to do something like this (see below) either:
>>
>> "component:aZone.clientId"
>>
>> Am I missing something, or is it simply a requirement to go through the java class?
>>
>> Thanks so much!
>> Jochen
>> ---
>> jochen@jochenfrey.com
>> +1.415.366.0450
>> @jochen_frey
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
---
jochen@jochenfrey.com
+1.415.366.0450
@jochen_frey
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: ComponentParameters - Binding Expressions - "component:"
Posted by Paul Stanton <pa...@mapshed.com.au>.
Why not just use:
<t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
<t:eventlink zone="aZone"/>
<t:zone t:id="aZone" id="aZone" />
</t:container>
?
On 7/03/2012 4:18 PM, Jochen Frey wrote:
> Hi!
>
> A general pattern for an Eventlink with an Ajax zone can look something like this:
>
> X.java:
> public class CTest {
> @InjectComponent @Property private Zone aZone;
> }
>
> X.tml:
> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
> <t:eventlink zone="prop:aZone.clientId"/>
> <t:zone t:id="aZone"/>
> </t:container>
>
>
> Where in essence I use a @Property in Java to generate the correct clientId for the t:zone parameter to the eventlink.
>
> I was wondering if there's a way to guarantee the correct clientID (not the t:id) without going through a Java @Property.
>
>
> Looking at the documentation one might hope that something like this would work:
>
> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_3.xsd">
> <t:eventlink zone=
> "component:aZone"
> />
> <t:zone t:id="aZone"/>
> </t:container>
>
>
> But "component:aZone" doesn't get the ID (which I expected from the documentation here: Binding Expressions - component: http://tapestry.apache.org/component-parameters.html), but instead I gets the actual Zone Object (which is great for many other use cases).
>
> And as far as I can tell, it's not possible to do something like this (see below) either:
>
> "component:aZone.clientId"
>
> Am I missing something, or is it simply a requirement to go through the java class?
>
> Thanks so much!
> Jochen
> ---
> jochen@jochenfrey.com
> +1.415.366.0450
> @jochen_frey
>
>
> ---------------------------------------------------------------------
> 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