[
https://issues.apache.org/jira/browse/MYFACES-2599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844513#action_12844513
]
Werner Punz edited comment on MYFACES-2599 at 3/12/10 2:35 PM:
---------------------------------------------------------------
Ok I fixed the issue quickly locally but again you have opened a "can of worms
here" first of all I personally think our exists check is valid due to the fact
that if the element is removed it is also removed from the execute cycle.
Practically I coded a bypass in which sent the id down so that it still is
executed.
But now to the second problem of fixing this. We have to send down the
viewstate which is more or less the viestate of our form (including the
detached element)
so now what happens is simply that we cannot send down the value of the element
becaus it also is no longer hosted in the form. Additional things become worse
because
within the request I cannot even determine the proper form anymore because the
element does not have a reference to it anymore and must use the first form
found on the page.
So detaching an element and hoping that the lifecycle executes properly is a no
go here, the bypass just suppresses an error message in that case which the
user otherwise would see and would instantly know that something in the dom is
wrong here.
In case of dojo this would be after the componet is created (aka after the new
dijit.blabla.component is issued with the replacement dom node issued by the
dijit widget itself!
As far as I know the dijit widgets keep references to the original node and
replacement node so this is doable even in a generic fashion.
I can try to program in a bypass for the id and value as well, but ultimately I
personally think that attaching to a detached element simply is wrong and then
hoping a proper xhr request is executed is even wronger, the component author
should simply attach to the new node instead and we should leave the error as
is, we simpy do not swallow the error but give the component author early
enough a feedback.
I am withholding my quick fixup code for now until this is discussed further on.
was (Author: werpu):
Ok I fixed the issue quickly locally but again you have opened a "can of
worms here" first of all I personally think our exists check is valid due to
the fact that if the element is removed it is also removed from the execute
cycle. Practically I coded a bypass in which sent the id down so that it still
is executed.
But now to the second problem of fixing this. We have to send down the
viewstate which is more or less the viestate of our form (including the
detached element)
so now what happens is simply that we cannot send down the value of the element
becaus it also is no longer hosted in the form. Additional things become worse
because
within the request I cannot even determine the proper form anymore because the
element does not have a reference to it anymore and must use the first form
found on the page.
So detaching an element and hoping that the lifecycle executes properly is a no
go here, the bypass just suppresses an error message in that case which the
user otherwise would see and would instantly know that something in the dom is
wrong here.
In case of dojo this would be after the componet is created (aka after the new
dijit.blabla.component is issued with the replacement dom node issued by the
dijit widget itself!
As far as I know the dijit widgets keep references to the original node and
replacement node so this is doable even in a generic fashion.
I can try to program in a bypass for the id and value as well, but ultimately I
personally think that attaching to a detached element simply is wrong and then
hoping a proper xhr request is executed is even wronger, the component author
should simply attach to the new node instead and we should leave the error as
is, we simpy do not swallow the error but give the component author early
enough a feedback.
I am withholding my quick fixup code for now until this is discussed further on.
Ok addition on a second thought attachment is also not possible, because you
have to send the original key value pair for the processing of the values
within the server side tree,
I will think things over again over the weekend, maybe I can find a bypass
which behaves well enough to fix this issue one way or the other (probably by
extending our viewState code to handle non attached elements and their values).
> ajax javascript checks for existence of triggering html element
> ---------------------------------------------------------------
>
> Key: MYFACES-2599
> URL: https://issues.apache.org/jira/browse/MYFACES-2599
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-beta-2
> Environment: Javascript
> Reporter: Ganesh Jung
>
> This one is a bit special. I remove the triggering element from the DOM,
> afterwards I trigger it's onchange method. Works with Mojarra, but MyFaces
> insists, that the triggering element must exist in the DOM, though this isn't
> necessary from the spec.
> <h:form id="testForm">
> <h:inputText id="test" value="#{myBean.test}" >
> <f:ajax render="test2"/>
> </h:inputText>
> <h:inputText id="test2" value="#{myBean.test}" />
> <script type="text/javascript">
> //<![CDATA[
> var myTest = document.getElementById("testForm:test");
> var test_onchange = myTest.onchange;
> myTest.parentNode.removeChild(myTest);
> test_onchange();
> //]]>
> </script>
> </h:form>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
