[
https://issues.apache.org/jira/browse/MYFACES-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12862569#action_12862569
]
Werner Punz edited comment on MYFACES-2640 at 4/30/10 3:43 AM:
---------------------------------------------------------------
Hello Mark thanks for all your code and suggestions one by one
First I will check your changes and fixes and mergen them in, but give me a
few days to process them.
(probably monday or tuesday I will have time to do this, have in mind I am
doing this in my non customer related time)
First again to your fixes, I have yet to check them, but it seems to me that
it still is the problem you reported in the beginning, again as I said in the
eg, wrap your elements
in a root node with the identifier of your client id, that ensures your
components will work on both
myfaces and mojarra in the PPR case. You cannot really fix the problem entirely
on javascript level within the impl, this is a problem of not having full
control over the rendering behavior on the spec side
by forcing the components in an update cycle before even opening the rendering.
So I can say, it is better to follow the recommendations of the EG than to try
to doctor within the specifics of
one impl, which then might break the compatibility to the other in your code.
The only way to solve this over all platforms in a clean manner is simply, wrap
your components into a root element
with the identifier of your clientId.
I can give you more details on how the rendering behavior works:
ppr request comes in for render:{id1}
automated server processing happens
the server issues a <update id="id1">
and then goes into the component to tell it to render itself!
so the component then renders its code
after that the server says </update>
what then happens is following response:
<update="id">
<[[CDATA
<div id="id1">
mycomponent code inputs etc...
</div>
]]>
</update>
so what happens now is simply if you do not wrap it into a root node or the
user does not by issuing an encapsulating element, the update happens on id1
and replaces it with several fragments
<update="id1">
<[[CDATA
<div id="id2">
<div id="id1">
</div>
<div id="id3">
</div>
</div>
]]>
</update>
so what happens now is you get following html
<div id="id2">
<div id="id1">
</div>
<div id="id3">
</div>
</div>
and at the next request
<div id="id2">
<div id="id2">
<div id="id1">
</div>
<div id="id3">
</div>
</div>
<div id="id3">
</div>
</div>
Which is clearly broken html.
You can deal to some degree with the problem on javascript level, but you
cannot cover all usecases without breaking the component of someone else doing
the same thing in a different combination and functionality.
And in the end doing it that way revealed after testing you will get problems
on mojarra and myfaces.
(Mojarra even more than MyFaces after my latest fixes).
This problem as I said can only be fixed entirely on spec level, by allowing a
path to the component authors
which gives them full control over the ppr rendering process.
(I filed an issue for that)
So again, it comes down to follow a certain pattern in your component design
process to be clean
I also cannot recommend to rely on specifics within myfaces, you will
definitely break compatibiltiy to Mojarra.
always render something along the lines of:
<update="id1">
<[[CDATA
<div id="id1">
</div>
]]>
</update>
not
<update="id1">
<[[CDATA
<div id="id2">
</div>
<div id="id1">
</div>
]]>
</update>
As I said this is not by me, this is an official recommendation from the EG
after I was querying them regarding this issue. I also filed a bug and a
proposal to fix this problem on spec level, but that will take some time to get
it resolved.
As for the second request fuzzy identifier handling:
Myfaces can only support what the spec gives and what the spec clearly not
breaks, eg. Extensions are possible but not totally different behavior.
A fuzzy element execute or render on javascript level is a definitive no go.
But for such cases you can use libraries like jquery or dojo query which
support things like that
I will give you some pseudo code (dojo query, since I am more familiar with
that one):
var executeList = dojo.query("#*myId");
var identifiers = [];
for(var cnt = 0; cnt <executeList.length; cnt++ {
identifiers.push(executeList[cnt].id)
}
return executeList.join(" ");
This is pseudo code, I am not sure if I got the query right, but you get the
idea,
as I said for the request and response object I am bound to the spec, I cannot
extend
it for fuzzy elements within execute and render on the official api level.
was (Author: werpu):
Hello Mark thanks for all your code and suggestions one by one
Ok first to the fuzzy elements
Myfaces can only support what the spec gives and what the spec clearly not
breaks, eg. Extensions are possible but not totally different behavior.
A fuzzy element execute or render on javascript level is a definitive no go.
But for such cases you can use libraries like jquery or dojo query which
support things like that
I will give you some pseudo code (dojo query, since I am more familiar with
that one):
var executeList = dojo.query("#*myId");
var identifiers = [];
for(var cnt = 0; cnt <executeList.length; cnt++ {
identifiers.push(executeList[cnt])
}
return executeList.join(" ");
This is pseudo code, I am not sure if I got the query right, but you get the
idea,
as I said for the request and response object I am bound to the spec, I cannot
extend
it for fuzzy elements within execute and render on the official api level.
I also cannot recommend to rely on specifics within myfaces, you will
definitely break compatibiltiy to Mojarra.
As for your reported bugs, I will check them one by one, and comment or merge
them in case by case, I will do that after the weekend, probably moday or
tuesday.
> (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
> 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.
