You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Ben Sommerville (JIRA)" <ta...@jakarta.apache.org> on 2006/08/10 13:13:15 UTC
[jira] Created: (TAPESTRY-1054) DojoAjaxResponseBuilder will never
render FormComponents
DojoAjaxResponseBuilder will never render FormComponents
---------------------------------------------------------
Key: TAPESTRY-1054
URL: http://issues.apache.org/jira/browse/TAPESTRY-1054
Project: Tapestry
Issue Type: Bug
Components: Framework
Affects Versions: 4.1.1
Reporter: Ben Sommerville
DojoAjaxResponseBuilder uses the client id of a component to determine whether or not to render it (see the contains method). Form components (children of AbstractFormComponent) will always have a null client id at this point & hence will never be rendered.
The form components seem to have a null client id because AbstractFormComponent has an abstract setClientId method. This causes tapestry to add a generated getClientId method that overrides the AbstractComponent.getClientId method. If you look at a form component in a debugger you can see the extra $clientId member variables that have been added to the concrete class.
The AbstractFormComponent setClientId method is only invoked by renderIdAttribute. Obviously this happens after the DojoAjaxResponseBuilder calls getClientId to determine whether the component should be rendered.
I think this can be fixed by removing the AbstractFormComponent setClientId method & adding a protected setClientId method to AbstractComponent (that just sets the _clientId member).
This will result in DojoAjaxResponseBuilder calling AbstractComponent.getClientId & being returned the bound id or the IComponent.getId. Either of which should allow it to properly determine whether the component is supposed to be rendered or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Assigned: (TAPESTRY-1054) DojoAjaxResponseBuilder will never
render FormComponents
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1054?page=all ]
Jesse Kuhnert reassigned TAPESTRY-1054:
---------------------------------------
Assignee: Jesse Kuhnert
> DojoAjaxResponseBuilder will never render FormComponents
> --------------------------------------------------------
>
> Key: TAPESTRY-1054
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1054
> Project: Tapestry
> Issue Type: Bug
> Components: Framework
> Affects Versions: 4.1.1
> Reporter: Ben Sommerville
> Assigned To: Jesse Kuhnert
>
> DojoAjaxResponseBuilder uses the client id of a component to determine whether or not to render it (see the contains method). Form components (children of AbstractFormComponent) will always have a null client id at this point & hence will never be rendered.
> The form components seem to have a null client id because AbstractFormComponent has an abstract setClientId method. This causes tapestry to add a generated getClientId method that overrides the AbstractComponent.getClientId method. If you look at a form component in a debugger you can see the extra $clientId member variables that have been added to the concrete class.
> The AbstractFormComponent setClientId method is only invoked by renderIdAttribute. Obviously this happens after the DojoAjaxResponseBuilder calls getClientId to determine whether the component should be rendered.
> I think this can be fixed by removing the AbstractFormComponent setClientId method & adding a protected setClientId method to AbstractComponent (that just sets the _clientId member).
> This will result in DojoAjaxResponseBuilder calling AbstractComponent.getClientId & being returned the bound id or the IComponent.getId. Either of which should allow it to properly determine whether the component is supposed to be rendered or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1054) DojoAjaxResponseBuilder will
never render FormComponents
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1054?page=comments#action_12427255 ]
Jesse Kuhnert commented on TAPESTRY-1054:
-----------------------------------------
Do you have an example where the current functionality breaks? I am currently able to update form components just fine using the ResponseBuilder semantics.
> DojoAjaxResponseBuilder will never render FormComponents
> --------------------------------------------------------
>
> Key: TAPESTRY-1054
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1054
> Project: Tapestry
> Issue Type: Bug
> Components: Framework
> Affects Versions: 4.1.1
> Reporter: Ben Sommerville
>
> DojoAjaxResponseBuilder uses the client id of a component to determine whether or not to render it (see the contains method). Form components (children of AbstractFormComponent) will always have a null client id at this point & hence will never be rendered.
> The form components seem to have a null client id because AbstractFormComponent has an abstract setClientId method. This causes tapestry to add a generated getClientId method that overrides the AbstractComponent.getClientId method. If you look at a form component in a debugger you can see the extra $clientId member variables that have been added to the concrete class.
> The AbstractFormComponent setClientId method is only invoked by renderIdAttribute. Obviously this happens after the DojoAjaxResponseBuilder calls getClientId to determine whether the component should be rendered.
> I think this can be fixed by removing the AbstractFormComponent setClientId method & adding a protected setClientId method to AbstractComponent (that just sets the _clientId member).
> This will result in DojoAjaxResponseBuilder calling AbstractComponent.getClientId & being returned the bound id or the IComponent.getId. Either of which should allow it to properly determine whether the component is supposed to be rendered or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Resolved: (TAPESTRY-1054) DojoAjaxResponseBuilder will never
render FormComponents
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1054?page=all ]
Jesse Kuhnert resolved TAPESTRY-1054.
-------------------------------------
Fix Version/s: 4.1.1
Resolution: Fixed
Fixed. Applied suggested changes and it worked out. Thanks :) Will deploy it in a couple minutes.
> DojoAjaxResponseBuilder will never render FormComponents
> --------------------------------------------------------
>
> Key: TAPESTRY-1054
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1054
> Project: Tapestry
> Issue Type: Bug
> Components: Framework
> Affects Versions: 4.1.1
> Reporter: Ben Sommerville
> Assigned To: Jesse Kuhnert
> Fix For: 4.1.1
>
> Attachments: TapBug-1054.zip
>
>
> DojoAjaxResponseBuilder uses the client id of a component to determine whether or not to render it (see the contains method). Form components (children of AbstractFormComponent) will always have a null client id at this point & hence will never be rendered.
> The form components seem to have a null client id because AbstractFormComponent has an abstract setClientId method. This causes tapestry to add a generated getClientId method that overrides the AbstractComponent.getClientId method. If you look at a form component in a debugger you can see the extra $clientId member variables that have been added to the concrete class.
> The AbstractFormComponent setClientId method is only invoked by renderIdAttribute. Obviously this happens after the DojoAjaxResponseBuilder calls getClientId to determine whether the component should be rendered.
> I think this can be fixed by removing the AbstractFormComponent setClientId method & adding a protected setClientId method to AbstractComponent (that just sets the _clientId member).
> This will result in DojoAjaxResponseBuilder calling AbstractComponent.getClientId & being returned the bound id or the IComponent.getId. Either of which should allow it to properly determine whether the component is supposed to be rendered or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAPESTRY-1054) DojoAjaxResponseBuilder will never
render FormComponents
Posted by "Ben Sommerville (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1054?page=all ]
Ben Sommerville updated TAPESTRY-1054:
--------------------------------------
Attachment: TapBug-1054.zip
Example attached.
Its fairly simple. There are two select inputs on the form, the goal is to update the options of the second select when the first select changes.
Hopefully you'll look at it and tell me where I've gone wrong :)
> DojoAjaxResponseBuilder will never render FormComponents
> --------------------------------------------------------
>
> Key: TAPESTRY-1054
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1054
> Project: Tapestry
> Issue Type: Bug
> Components: Framework
> Affects Versions: 4.1.1
> Reporter: Ben Sommerville
> Assigned To: Jesse Kuhnert
> Attachments: TapBug-1054.zip
>
>
> DojoAjaxResponseBuilder uses the client id of a component to determine whether or not to render it (see the contains method). Form components (children of AbstractFormComponent) will always have a null client id at this point & hence will never be rendered.
> The form components seem to have a null client id because AbstractFormComponent has an abstract setClientId method. This causes tapestry to add a generated getClientId method that overrides the AbstractComponent.getClientId method. If you look at a form component in a debugger you can see the extra $clientId member variables that have been added to the concrete class.
> The AbstractFormComponent setClientId method is only invoked by renderIdAttribute. Obviously this happens after the DojoAjaxResponseBuilder calls getClientId to determine whether the component should be rendered.
> I think this can be fixed by removing the AbstractFormComponent setClientId method & adding a protected setClientId method to AbstractComponent (that just sets the _clientId member).
> This will result in DojoAjaxResponseBuilder calling AbstractComponent.getClientId & being returned the bound id or the IComponent.getId. Either of which should allow it to properly determine whether the component is supposed to be rendered or not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org