You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Pierce Wetter <pi...@paceap.com> on 2010/08/17 03:14:29 UTC
[T5.2] Problem with nested Ajax Updates
I found a cool Safari Extension called "Better Source" that helped me get closer on this problem, I'm hoping someone can help me beyond this. .
Basically, the idea is that I want a grid that is initially hidden. Clicking on a button reveals a grid, clicking on an item in the grid reveals a detail zone for the item in the grid.
The grid works separately, but not when nested.
So we start with a t:zone wrapped around a link:
<t:zone t:id="popupZonelocations">
<a class="button" t:type="eventlink" t:zone="popupZonelocations" t:context="literal:locations" t:event="showToMany" t:id="showlocaitons">Show Locations</a>
</t:zone>
That returns the block below:
<t:block t:id="locationsGridBlock">
<t:pace.grid.ActivationLocationGrid activationlocationSource="user.locations" t:id="locationsgrid"/>
</t:block>
My ActivationLocationGrid component is basically:
<zone i:id="details" />
<grid>
<t:parameter name="firstCell>
<eventlink zone="details">
</t:parameter>
</grid>
<block t:id="details">
stuff
</block>
So basically, after the load, we should have:
<zone id='first zone'>
<zone id ='second zone'>
<grid>
<link zone='second zone'>
</grid>
</zone>
</zone>
Here's what the resulting HTML source looks like after the grid has been revealed. It looks like what has happened is that Tapestry has generated some sort of id suffix: 12a7d6e06a7 Which it then proceeds to append to the IDs of everything in the result of loading the first zone. But its not propogating that suffix everywhere properly, because then the links inside the grid don't work, at least my links don't, but the sort headers do! Digging in a bit more, it seems that the issue is that the zoneId's don't have the suffix when the list of linkZones is generated, which I can show after the HTML:
HTML:
<div class="t-zone" id="popupZonelocations" style="background-image: none; background-color: rgb(255, 255, 255); ">
227 <span class="text">Locations has 13 items <br></span>
228
229
230 <div class="t-zone" id="popupZoneActivationLocation_12a7d6e06a7">
231 </div>
232 <div id="gridAL_12a7d6e06a7"><div class="t-data-grid">
233
234
235
236 <table class="t-data-grid">
237 <thead><tr><th class="uuid t-first"><a id="sort_12a7d6e06a7" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/uuid/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86">uuid</a><a id="sort2_12a7d6e06a7" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/uuid/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86"><img alt="[Sortable]" class="t-sort-icon" src="/Zardoz2/assets/1.0-SNAPSHOT/core/components/sortable.png"></a></th><th class="userName t-sort-column-descending"><a id="sort_12a7d6e06a7_0" class="t-sort-column-descending" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/userName/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86">userName</a><a id="sort2_12a7d6e06a7_0" class="t-sort-column-descending" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/userName/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86"><img alt="[Desc]" class="t-sort-icon" src="/Zardoz2/assets/1.0-SNAPSHOT/core/components/sort-desc.png"></a></th><th class="userDescription t-last"><a id="sort_12a7d6e06a7_1" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/userDescription/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86">userDescription</a><a id="sort2_12a7d6e06a7_1" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/userDescription/gridAL_12a7d6e06a7?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86"><img alt="[Sortable]" class="t-sort-icon" src="/Zardoz2/assets/1.0-SNAPSHOT/core/components/sortable.png"></a></th></tr></thead>
238 <tbody>
239 <tr class="even t-first"><td class="uuid">
240 <a id="popupActivationLocationDetauls_12a7d6e06a7" class="buttonPopup" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid:popup/BD84E635-FC4A-42A6-A59D-5E49E9CCB66C?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86">BD84E635-FC4A-42A6-A59D-5E49E9CCB66C</a>
241 </td><td class="userName t-sort-column-descending">iLok2 #2</td><td class="userDescription">iLok Newly Registered To Pierce</td></tr><tr class="odd"><td class="uuid">
242 <a id="popupActivationLocationDetauls_12a7d6e06a7_0" class="buttonPopup" href="/Zardoz2/pace/view/user.userviewlong.locationsgrid:popup/0C41FFA2-E825-485E-A7D8-55038194830F?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86">0C41FFA2-E825-485E-A7D8-55038194830F</a>
243 </td><td class="userName t-sort-column-descending">iLok2 #1</td><td class="userDescription">iLok Newly Registered To Pierce</td></tr><tr class="even"><td class="uuid">
Link Zone list excerpt showing both the parameters for a grid sort label, and the parameters for a link inside the grid:
{
"linkId" : "sort2_12a7d8dbe0e_1",
"url" : "/Zardoz2/pace/view/user.userviewlong.locationsgrid.gridal.columns:sort/userDescription/gridAL_12a7d8dbe0e?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86",
"zoneId" : "gridAL_12a7d8dbe0e"
},
{
"linkId" : "popupActivationLocationDetauls_12a7d8dbe0e",
"url" : "/Zardoz2/pace/view/user.userviewlong.locationsgrid:popup/107A0D2E-6F62-44E7-B3E9-D3D47C0A11D3?t:ac=29F85122-60BB-43C0-A086-D0FF0AD64D86",
"zoneId" : "popupZoneActivationLocation"
},
Note that the Grid sort link has the right zoneId, and that it's told to update the right zone, in that the suffix has been added to the zoneId specifier.
The link inside the grid is not told to update the right zone because the suffix has NOT been added.
Pierce
Re: [T5.2] Problem with nested Ajax Updates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 17 Aug 2010 18:08:27 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
> Er, yeah, but my point was that the first zone doesn't get a random
> suffix, its only the nested zone that does.
Yep, I wasn't clear in first place: I should have said that zones (and
other ClientElement objects) get a random suffix when rendered in an AJAX
request unless they have an id explicitly set.
--
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: [T5.2] Problem with nested Ajax Updates
Posted by Pierce Wetter <pi...@paceap.com>.
On Aug 17, 2010, at 12:21 PM, Thiago H. de Paula Figueiredo wrote:
> On Tue, 17 Aug 2010 15:33:09 -0300, Pierce Wetter <pi...@paceap.com> wrote:
>
>>> To avoid creating elements with repeated ids, when you don't provide one explicitly, the components generate an id with a random suffix.
>> Well, that's not quite true. That's why it seems like a bug to me.
>>
>> <zone t:id="first" />
>>
>> Will get generated as:
>>
>> <div id="first" />
>>
>> But if you nest them:
>>
>> <zone t:id="first" />
>> <block>
>> <zone t:id="second" />
>> <a zone="second" id="alink"/>
>> </block>
>>
>> You'll end up with:
>>
>> <div id="first">
>> <div id="second_54987654">
>> </div>
>> <a id="alink_54987654" />
>> </div>
>
> That's exactly what I said previously. :)
Er, yeah, but my point was that the first zone doesn't get a random suffix, its only the nested zone that does.
Pierce
Re: [T5.2] Problem with nested Ajax Updates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 17 Aug 2010 15:33:09 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
>> To avoid creating elements with repeated ids, when you don't provide
>> one explicitly, the components generate an id with a random suffix.
> Well, that's not quite true. That's why it seems like a bug to me.
>
> <zone t:id="first" />
>
> Will get generated as:
>
> <div id="first" />
>
> But if you nest them:
>
> <zone t:id="first" />
> <block>
> <zone t:id="second" />
> <a zone="second" id="alink"/>
> </block>
>
> You'll end up with:
>
> <div id="first">
> <div id="second_54987654">
> </div>
> <a id="alink_54987654" />
> </div>
That's exactly what I said previously. :)
> But maybe not. Perhaps its a documentation error, because links are
> supposed to take the client id of the zone to update, not the t:id, and
> we could add some notes to t:zone to clarify.
You're right: you need to pass the zone client id, not it's t:id.
> It's a funny way of saying "ass backwards". Technically, its called a
> "Spoonerism" after a a particular Oxford professor:
> http://en.wikipedia.org/wiki/Spoonerism
> It's particularly humorous for an English speaker because you're both
> saying something is backwards, and demonstrating that its backwards.
Hehehe. Thanks for the explanation. :)
--
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: [T5.2] Problem with nested Ajax Updates
Posted by Pierce Wetter <pi...@paceap.com>.
On Aug 17, 2010, at 8:53 AM, Thiago H. de Paula Figueiredo wrote:
> On Tue, 17 Aug 2010 10:40:36 -0300, Pierce Wetter <pi...@paceap.com> wrote:
>
>> Yes, but id kind-of-sort-of gets set by t:id already if its not set. Setting the client id as a workaround to force the id seems bassackwards to me. I'm wondering if this is related to 1096.
>
> To avoid creating elements with repeated ids, when you don't provide one explicitly, the components generate an id with a random suffix.
Well, that's not quite true. That's why it seems like a bug to me.
<zone t:id="first" />
Will get generated as:
<div id="first" />
But if you nest them:
<zone t:id="first" />
<block>
<zone t:id="second" />
<a zone="second" id="alink"/>
</block>
You'll end up with:
<div id="first">
<div id="second_54987654">
</div>
<a id="alink_54987654" />
</div>
Which all looks ok on the HTML side, but the JSon array that is sent so that Tapestry can wire up the links correctly then has:
zoneID = "second";
instead of
zoneID = "second_54987654";
This is just a guess, but I think the bug is that the code that generates the array for the javascript is using the t:id rather than the client id. It only manifests when you nest or loop over zones, because otherwise t:id and clientId are the same value. This bug seems to relate to it: https://issues.apache.org/jira/browse/TAP5-1061 but it doesn't look like anyone closed the loop maybe? And I'm pretty sure its a bug, because the JSON array needs the clientId in zoneID, but what it has is the serverId, so it must be a bug.
But maybe not. Perhaps its a documentation error, because links are supposed to take the client id of the zone to update, not the t:id, and we could add some notes to t:zone to clarify.
>
> I'm not an English native speaker, so what's 'bassackwards'? :)
It's a funny way of saying "ass backwards". Technically, its called a "Spoonerism" after a a particular Oxford professor: http://en.wikipedia.org/wiki/Spoonerism
It's particularly humorous for an English speaker because you're both saying something is backwards, and demonstrating that its backwards.
Pierce
Re: [T5.2] Problem with nested Ajax Updates
Posted by Michael Gentry <mg...@masslight.net>.
It is a politically correct attempt at saying "ass backwards" ... :-)
mrg
On Tue, Aug 17, 2010 at 11:53 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> I'm not an English native speaker, so what's 'bassackwards'? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.2] Problem with nested Ajax Updates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 17 Aug 2010 10:40:36 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
> Yes, but id kind-of-sort-of gets set by t:id already if its not set.
> Setting the client id as a workaround to force the id seems bassackwards
> to me. I'm wondering if this is related to 1096.
To avoid creating elements with repeated ids, when you don't provide one
explicitly, the components generate an id with a random suffix.
I'm not an English native speaker, so what's 'bassackwards'? :)
--
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: [T5.2] Problem with nested Ajax Updates
Posted by Pierce Wetter <pi...@paceap.com>.
On Aug 16, 2010, at 8:14 PM, Thiago H. de Paula Figueiredo wrote:
> On Mon, 16 Aug 2010 23:51:00 -0300, Pierce Wetter <pi...@paceap.com> wrote:
>
>> Ah, just found that in Jira.
>> So shouldn't setting t:id set the id as well?
>
> They're different ids: t:id is server-side, id is client-side, so I really don't know if that would be a good idea all the time.
>
> You can force a client element to render its id using the RenderClientId mixin (http://tapestry.apache.org/tapestry5.2-dev/tapestry-core/ref/org/apache/tapestry5/corelib/mixins/RenderClientId.html).
Yes, but id kind-of-sort-of gets set by t:id already if its not set. Setting the client id as a workaround to force the id seems bassackwards to me. I'm wondering if this is related to 1096.
Pierce
Re: [T5.2] Problem with nested Ajax Updates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 16 Aug 2010 23:51:00 -0300, Pierce Wetter <pi...@paceap.com>
wrote:
> Ah, just found that in Jira.
> So shouldn't setting t:id set the id as well?
They're different ids: t:id is server-side, id is client-side, so I really
don't know if that would be a good idea all the time.
You can force a client element to render its id using the RenderClientId
mixin
(http://tapestry.apache.org/tapestry5.2-dev/tapestry-core/ref/org/apache/tapestry5/corelib/mixins/RenderClientId.html).
--
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: [T5.2] Problem with nested Ajax Updates
Posted by Pierce Wetter <pi...@paceap.com>.
On Aug 16, 2010, at 6:50 PM, Thiago H. de Paula Figueiredo wrote:
> Hi!
>
> Provide the zones' ids explicitly and you don't probably have more problems.
>
> There was a recent similar discussion here: http://tapestry.1045711.n5.nabble.com/Component-with-a-Zone-and-ActionLink-in-a-loop-td2634998.html#a2634998, but with zones inside a loop.
Ah, just found that in Jira.
So shouldn't setting t:id set the id as well?
Pierce
Re: [T5.2] Problem with nested Ajax Updates
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Hi!
Provide the zones' ids explicitly and you don't probably have more
problems.
There was a recent similar discussion here:
http://tapestry.1045711.n5.nabble.com/Component-with-a-Zone-and-ActionLink-in-a-loop-td2634998.html#a2634998,
but with zones inside a loop.
--
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