You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Christian Riedel (Created) (JIRA)" <ji...@apache.org> on 2011/11/06 19:47:51 UTC
[jira] [Created] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Zone-Update inside a form inside a block (with generated ids) not working
-------------------------------------------------------------------------
Key: TAP5-1746
URL: https://issues.apache.org/jira/browse/TAP5-1746
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.3
Reporter: Christian Riedel
Priority: Critical
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{noformat}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{noformat}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{code}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{code}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{noformat}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{noformat}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {code}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {code}
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166461#comment-13166461 ]
Christian Riedel commented on TAP5-1746:
----------------------------------------
True, this works! I was thinking in too complicated terms and forgot about that somehow...
Just checked the documentation and found it being well enough documented as well (just the MultiZoneUpdate part should be replaced with an AjaxResponseRenderer example!).
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{code}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{code}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel closed TAP5-1746.
----------------------------------
Resolution: Not A Problem
...closing that issue, although I think there could be some automatic mechanism to support my initial approach (without explicit client id).
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel closed TAP5-1746.
----------------------------------
Resolution: Not A Problem
...closing that issue, although I think there could be some automatic mechanism to support my initial approach (without explicit client id).
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{code}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{code}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{noformat}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{noformat}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {{code}}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {{code}}
> --> after a zone-update the "block" property resolves to the following block:
> {{noformat}}
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> {{noformat}}
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> {{noformat}}
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> {{noformat}}
> {{noformat}}
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> {{noformat}}
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> {{noformat}}
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> {{noformat}}
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> {{noformat}}
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> {{noformat}}
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{noformat}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{noformat}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {noformat}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {noformat}
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166461#comment-13166461 ]
Christian Riedel commented on TAP5-1746:
----------------------------------------
True, this works! I was thinking in too complicated terms and forgot about that somehow...
Just checked the documentation and found it being well enough documented as well (just the MultiZoneUpdate part should be replaced with an AjaxResponseRenderer example!).
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{noformat}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{noformat}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {noformat}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {noformat}
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{code}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{code}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
can someone activate code formatting? :)
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Denis Stepanov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166263#comment-13166263 ]
Denis Stepanov commented on TAP5-1746:
--------------------------------------
When you have an ajax response client ids are generated with a random string, you should define the client id for the updateZone:
<t:zone t:id="updateZone" id="updateZone">
"can someone activate code formatting? :)"
+1
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{code}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{code}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Denis Stepanov (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166263#comment-13166263 ]
Denis Stepanov commented on TAP5-1746:
--------------------------------------
When you have an ajax response client ids are generated with a random string, you should define the client id for the updateZone:
<t:zone t:id="updateZone" id="updateZone">
"can someone activate code formatting? :)"
+1
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{code}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{code}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{noformat}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{noformat}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {code}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {code}
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{code}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{code}
--> after a zone-update the "block" property resolves to the following block:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
public String getUpdateZoneId() {
return updateZone.getClientId();
}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
can someone activate code formatting? :)
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Riedel updated TAP5-1746:
-----------------------------------
Description:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{code}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{code}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
was:
Zone-Updates are not working under certain conditions when being rendered inside a block.
If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
{{noformat}}
<t:zone t:id="outerZone">
<t:delegate t:to="block" />
</t:zone>
{{noformat}}
--> after a zone-update the "block" property resolves to the following block:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
</t:form>
</t:block>
{{noformat}}
The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
{{noformat}}
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
{{noformat}}
{{noformat}}
public String getUpdateZoneId() {
return updateZone.getClientId();
}
{{noformat}}
However, this won't work as expected, either.
Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
{{noformat}}
@OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
void onValueSelected() {
// this will also fail on the client side
ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
}
{{noformat}}
Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
Switch the order of the components:
{{noformat}}
<t:block t:id="editBlock">
<t:form t:id="editForm">
<t:zone t:id="updateZone">
<t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
</t:zone>
<t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
</t:form>
</t:block>
{{noformat}}
Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> {{code}}
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> {{code}}
> --> after a zone-update the "block" property resolves to the following block:
> {{noformat}}
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> {{noformat}}
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> {{noformat}}
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> {{noformat}}
> {{noformat}}
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> {{noformat}}
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> {{noformat}}
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> {{noformat}}
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> {{noformat}}
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> {{noformat}}
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145069#comment-13145069 ]
Christian Riedel commented on TAP5-1746:
----------------------------------------
see also the discussion here: http://tapestry-users.832.n2.nabble.com/T5-3-rc-3-zone-inside-a-form-with-generated-ids-not-working-td6968194.html
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1746) Zone-Update inside a form inside a
block (with generated ids) not working
Posted by "Christian Riedel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145069#comment-13145069 ]
Christian Riedel commented on TAP5-1746:
----------------------------------------
see also the discussion here: http://tapestry-users.832.n2.nabble.com/T5-3-rc-3-zone-inside-a-form-with-generated-ids-not-working-td6968194.html
> Zone-Update inside a form inside a block (with generated ids) not working
> -------------------------------------------------------------------------
>
> Key: TAP5-1746
> URL: https://issues.apache.org/jira/browse/TAP5-1746
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.3
> Reporter: Christian Riedel
> Priority: Critical
>
> Zone-Updates are not working under certain conditions when being rendered inside a block.
> If an outer zone receives a zone-update the components inside the content of the delegated block will have generated ids:
> <t:zone t:id="outerZone">
> <t:delegate t:to="block" />
> </t:zone>
> --> after a zone-update the "block" property resolves to the following block:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="updateZone" />
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> </t:form>
> </t:block>
> The select component "updateSelectBox" won't find the zone "updateZone" since the real clientId has a randomly generated number appended.
> To circumvent this feature one can write a getter to obtain the generated id each time the block renders:
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
> public String getUpdateZoneId() {
> return updateZone.getClientId();
> }
> However, this won't work as expected, either.
> Firstly because the clientId is always null at that point. It's being called before the zone's beginRender method is invoked.
> Secondly because you need this client id in the event handler as well. Even if you'd be able to get the id at this point, the execution of the processReply method in tapestry.js will fail because it can't find the zone. The id has been generated once more and is not yet known to the client:
> @OnEvent(component = "updateSelectBox", value = EventConstants.VALUE_CHANGED)
> void onValueSelected() {
> // this will also fail on the client side
> ajaxResponseRenderer.addRender(getUpdateZoneId(), updateZone);
> }
> Now what I found being the only workaround is to store the client id once it's generated, i.e. when the block renders the first time.
> But as I stated earlier the id is null before beginRender is called. So another workaround must be applied:
> Switch the order of the components:
> <t:block t:id="editBlock">
> <t:form t:id="editForm">
>
> <t:zone t:id="updateZone">
> <t:select t:id="theOtherValue" t:model="otherValues" t:value="other" blankOption="never" />
> </t:zone>
>
> <t:select t:id="updateSelectBox" t:model="values" t:value="selected" t:zone="prop:updateZoneId" />
>
> </t:form>
> </t:block>
> Now that the "updateZone" renders before the "updateSelectBox", "prop:updateZoneId" is able to return the correct id.
> Please make the first example work! It should not be necessary to deal with the generated ids. Tapestry.js should implement some magic-code to find out the correct zone if "updateZone" is referenced in the template. Since all components within the same block have the same generated value appended it might actually be possible to find the correct zone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira