[
https://issues.apache.org/jira/browse/MYFACES-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863819#action_12863819
]
Werner Punz commented on MYFACES-2640:
--------------------------------------
This is an entirely different issue here what we are dealing with is heavy dom
manipulation on the side of jquery.
Which means we have to resolve that from jqueries side as well.
The dialog is the nastiest of all components (well the html editor is equally
nasty).
The reason for this is, that html dialogs usually are done following way:
Rip the source for the dialog out of any element in existence, put it directly
underneath your
document dom node, so that position absolute works over all browsers in an
absolute way.
To the worse the original element will be heavily decorated by other constructs
which resemble the dialog controls)
(You can easily see that if you open firebug, the original span is shifted to
the document node and outside of the form and everything is decorated)
So what we have here is a nasty detachment issue, which is not fixable on the
jsf.js side but instead has to be fixed outside of it, to the worse, every
javascript complib does all this slightly different so there is no generic
cleanup way, but if we stay on the jquery side there is a working solution to
your problem:
<h:commandLink id="button2"
onclick="$('#myDialog').dialog('destroy');$('#myDialog').remove();
jsf.ajax.request(this,event,{execute:'@this', render:'myDialog_placeHolder'} );
return false;" action="#{myBean2.doSearch}" value="press me for next ajax"
>
</h:commandLink>
<h:panelGroup id="myDialog_placeHolder">
<h:panelGroup styleClass="myDlg" id="myDialog">
<h:panelGroup id="content">
#{myBean2.refresh}
</h:panelGroup>
</h:panelGroup>
<script type="text/javascript">
/**
* we delay the dialog buildup slightly
* that way everything should be updated in the dom
*/
$("#myDialog").dialog();
</script>
</h:panelGroup>
So what we do here is following, we wrap the dialog into an element with a
fixed identifier (dependend on our client id, that element never will be
changed and is the placeholder for future updates.
Then we let jquery do the work on the dialog, which will automatically end
outside of the form (be careful if you put input elements into the dialog this
will fail unless you wrap a form into it)
And then before issuing the ppr update we clear the dialog and kill the
detached element, after that jsf.ajax can perform its part cleanly.
Alternatively you can make a listener over the jsf.ajax event queue to see
which elements get rendered before or shortly after the request and then do the
element killing there.
Sorry for having this so complicated but this is really an issue which is not
solvable within the scope of jsf.ajax.
The only bug in all this is, that the jquery $('#myDialog').dialog('destroy');
does not restore the dom node in its original position but leaves it in the
new one, (this is a severe bug if you ask me) hence we have to issue
a following $('#myDialog').remove(); to clean up the dom tree properly. This
definitely has to be sent to the jquery guys!
> (JSF.js) Ajax Render component problem, replace with whole fragment not one
> element.
> ------------------------------------------------------------------------------------
>
> Key: MYFACES-2640
> URL: https://issues.apache.org/jira/browse/MYFACES-2640
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-beta-3
> Environment: tomcat 6.0.20 java (mac os x )
> Reporter: Mark Li
> Fix For: 2.0.1-SNAPSHOT
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> after ajax submit, jsf.js will re-render some element depending on
> jsf.ajax.request({render:" some elements "});
> but this js code will cause some problem.
> jsf.js:
> myfaces._impl._util._Utils.replaceHtmlItem = function (request, context,
> itemIdToReplace, newTag, form) {
> ......
> var fragment = range.createContextualFragment(newTag);
> evalNode = item.parentNode.replaceChild(fragment, item)
> .....
> }
> sometime fragment will has more than one childNodes, or the childNode not has
> clientId, but the childNode of childNode has clientId.
> this will cause html unstable.
> Please fix it.
> this is my suggestion:
> myfaces._impl._util._Utils.replaceHtmlItem = function (request, context,
> itemIdToReplace, newTag, form) {
> .............
> Orginal:
> var fragment = range.createContextualFragment(newTag);
> evalNode = item.parentNode.replaceChild(fragment, item)
> fix:
> var fragment = range.createContextualFragment(newTag);
> var replaceItem =
> myfaces._impl._util._Utils.findHtmlItemFromFragment(fragment,
> itemIdToReplace);
> if(replaceItem == null)replaceItem = fragment;
> evalNode = item.parentNode.replaceChild(replaceItem, item)
> ..................
> }
> myfaces._impl._util._Utils.findHtmlItemFromFragment = function(fragment,
> itemId){
> if(fragment.childNodes == null)
> return null;
> for(var i = 0; i < fragment.childNodes.length ; i++ ){
> var c = fragment.childNodes[i];
> if(c.id == itemId)
> return c;
> }
> for(var i = 0; i < fragment.childNodes.length ; i++ ){
> var c = fragment.childNodes[i];
> var item =
> myfaces._impl._util._Utils.findHtmlItemFromFragment(c, itemId);
> if(item != null)
> return item;
> }
> return null;
> };
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
