You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "sean schofield (JIRA)" <my...@incubator.apache.org> on 2005/10/11 19:10:04 UTC
[jira] Created: (MYFACES-692) AjaxPhaseListener does not work with forceId
AjaxPhaseListener does not work with forceId
--------------------------------------------
Key: MYFACES-692
URL: http://issues.apache.org/jira/browse/MYFACES-692
Project: MyFaces
Type: Bug
Components: Sandbox
Versions: Nightly
Reporter: sean schofield
Priority: Blocker
I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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
[jira] Commented: (MYFACES-692) AjaxPhaseListener does not work with forceId
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-692?page=comments#action_12356367 ]
Martin Marinschek commented on MYFACES-692:
-------------------------------------------
I've thought about this again - and in fact there is a problem with force-id. I should be able to find a component by its id no matter what - even if forceId is set. Don't you think so?
regards,
Martin
> AjaxPhaseListener does not work with forceId
> --------------------------------------------
>
> Key: MYFACES-692
> URL: http://issues.apache.org/jira/browse/MYFACES-692
> Project: MyFaces
> Type: Bug
> Components: Sandbox
> Versions: Nightly
> Reporter: sean schofield
> Priority: Blocker
>
> I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
> I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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
[jira] Closed: (MYFACES-692) AjaxPhaseListener does not work with forceId
Posted by "sean schofield (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-692?page=all ]
sean schofield closed MYFACES-692:
----------------------------------
Fix Version: Nightly
Resolution: Fixed
> AjaxPhaseListener does not work with forceId
> --------------------------------------------
>
> Key: MYFACES-692
> URL: http://issues.apache.org/jira/browse/MYFACES-692
> Project: MyFaces
> Type: Bug
> Components: Sandbox
> Versions: Nightly
> Reporter: sean schofield
> Fix For: Nightly
>
> I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
> I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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
[jira] Commented: (MYFACES-692) AjaxPhaseListener does not work with forceId
Posted by "Martin Marinschek (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-692?page=comments#action_12332347 ]
Martin Marinschek commented on MYFACES-692:
-------------------------------------------
You are right - there are now some issues coming up with the intended AJAX-architecture.
We will need something more than we have right now, and maybe you want to start a developer discussion?
regards,
Martin
> AjaxPhaseListener does not work with forceId
> --------------------------------------------
>
> Key: MYFACES-692
> URL: http://issues.apache.org/jira/browse/MYFACES-692
> Project: MyFaces
> Type: Bug
> Components: Sandbox
> Versions: Nightly
> Reporter: sean schofield
> Priority: Blocker
>
> I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
> I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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
[jira] Commented: (MYFACES-692) AjaxPhaseListener does not work with forceId
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-692?page=comments#action_12356368 ]
Martin Marinschek commented on MYFACES-692:
-------------------------------------------
P.S: I am changing this from a blocker to major, as it affects a sandbox component.
> AjaxPhaseListener does not work with forceId
> --------------------------------------------
>
> Key: MYFACES-692
> URL: http://issues.apache.org/jira/browse/MYFACES-692
> Project: MyFaces
> Type: Bug
> Components: Sandbox
> Versions: Nightly
> Reporter: sean schofield
> Priority: Blocker
>
> I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
> I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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
[jira] Updated: (MYFACES-692) AjaxPhaseListener does not work with forceId
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-692?page=all ]
Martin Marinschek updated MYFACES-692:
--------------------------------------
Priority: Major (was: Blocker)
> AjaxPhaseListener does not work with forceId
> --------------------------------------------
>
> Key: MYFACES-692
> URL: http://issues.apache.org/jira/browse/MYFACES-692
> Project: MyFaces
> Type: Bug
> Components: Sandbox
> Versions: Nightly
> Reporter: sean schofield
>
> I tried using inputSuggestAjax but ran into problems with forceId. The problem is that AjaxPhaseListener is relying on the clientId to be the default JSF assigned id that is used to identify the path of the component. It attempts to lookup the component using findComponentById which won't work with forceId.
> I suggest we consider changing the AjaxComponent interface from encodeAjax to processAjax. Then call every component in the tree giving each component that is intanceof AjaxComponent a chance to processAjax. Then the components themselves can check the submitted value against their clientId (simliar to decoding.) This approach will likely be slower but IMO forceId is a must have for my javascript (and there is more of it coming in the next spec.)
--
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