Re: Myfaces 2.0 PPR ResponseWriter impl
Pro elements, it is faster because you can ommit client side parsing! Mojarra probably does nothing currently in this regard! I am not sure how they are going to handle the embedded scripts case within a ppr request, because with the standard apis you cannot directly open an eval from a component! But I will leave the extension for now, and leave it to the client! But we need to extend the client script parser to script src= constructs, we do not cover that yet, we have the functionality in place to load scripts dynamically but the parser is not fully there yet as far as I have seen! However there is one thing we have to implement on the server side, if an insert or update part is opened on the ppr response writer, and someone issues an eval also, what do we do, I have to recheck the spec if something is specified, but I think there was nothing! Either we can delay the eval until the insert or update is terminated (what I would prefer, or we have to throw an exception!) Anyway I personally think this entire area needs more refinement in jsf 2.1! Werner Ganesh schrieb: Hi, Let me summarize the arguments against pushing scripts to the eval section: 1. scripts inside !-- comments would suddenly become executed if facelets.SKIP_COMMENTS is false (which is the Facelets default) 2. omitting scripts within the markup may damage the layout 3. script order gets messed up if scripts rendered via startElement always come last 4. mojarra doesn't do it No pro arguments in sight, I guess ... Best regards, Ganesh Werner Punz schrieb: Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
Re: Myfaces 2.0 PPR ResponseWriter impl
Ok my personal guess is to move this discussion to the comments list for the jsf spec, I have not really found anything describing the correct behavior! Werner Werner Punz schrieb: Pro elements, it is faster because you can ommit client side parsing! Mojarra probably does nothing currently in this regard! I am not sure how they are going to handle the embedded scripts case within a ppr request, because with the standard apis you cannot directly open an eval from a component! But I will leave the extension for now, and leave it to the client! But we need to extend the client script parser to script src= constructs, we do not cover that yet, we have the functionality in place to load scripts dynamically but the parser is not fully there yet as far as I have seen! However there is one thing we have to implement on the server side, if an insert or update part is opened on the ppr response writer, and someone issues an eval also, what do we do, I have to recheck the spec if something is specified, but I think there was nothing! Either we can delay the eval until the insert or update is terminated (what I would prefer, or we have to throw an exception!) Anyway I personally think this entire area needs more refinement in jsf 2.1! Werner Ganesh schrieb: Hi, Let me summarize the arguments against pushing scripts to the eval section: 1. scripts inside !-- comments would suddenly become executed if facelets.SKIP_COMMENTS is false (which is the Facelets default) 2. omitting scripts within the markup may damage the layout 3. script order gets messed up if scripts rendered via startElement always come last 4. mojarra doesn't do it No pro arguments in sight, I guess ... Best regards, Ganesh Werner Punz schrieb: Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
Re: Myfaces 2.0 PPR ResponseWriter impl
Ok I have sent a mail regarding all this to the jcr-314 comments list, I hope this will trigger a discussion. Regarding our implementation, lets leave it client side and improve a little bit upon it (which means add script src= handling on the client, the javascript dynamic loading code is already in place)! I think Ganesh is right that a server side treatment would be faster but it opens a can of worms which might break compatibility and causes too many headaches! We always can introduce server side script handling later on once we know we have to do it, one way or the other (for any reason) Werner Werner Punz schrieb: Ok my personal guess is to move this discussion to the comments list for the jsf spec, I have not really found anything describing the correct behavior! Werner Werner Punz schrieb: Pro elements, it is faster because you can ommit client side parsing! Mojarra probably does nothing currently in this regard! I am not sure how they are going to handle the embedded scripts case within a ppr request, because with the standard apis you cannot directly open an eval from a component! But I will leave the extension for now, and leave it to the client! But we need to extend the client script parser to script src= constructs, we do not cover that yet, we have the functionality in place to load scripts dynamically but the parser is not fully there yet as far as I have seen! However there is one thing we have to implement on the server side, if an insert or update part is opened on the ppr response writer, and someone issues an eval also, what do we do, I have to recheck the spec if something is specified, but I think there was nothing! Either we can delay the eval until the insert or update is terminated (what I would prefer, or we have to throw an exception!) Anyway I personally think this entire area needs more refinement in jsf 2.1! Werner Ganesh schrieb: Hi, Let me summarize the arguments against pushing scripts to the eval section: 1. scripts inside !-- comments would suddenly become executed if facelets.SKIP_COMMENTS is false (which is the Facelets default) 2. omitting scripts within the markup may damage the layout 3. script order gets messed up if scripts rendered via startElement always come last 4. mojarra doesn't do it No pro arguments in sight, I guess ... Best regards, Ganesh Werner Punz schrieb: Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, So here is my proposal and I am working on it already. Scan for script startElement tags and postpone the rendering of those until the endUpdate or endInsert is issued! Scan for script src and add some dynamic loading code to it (already finished in the javascripts) and postpone it as well! -1 for script scanning on the server side. You will get into serious troubles with this. 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. eval within an active update or insert also causes the same delay behavior! if non update or insert is issued before then simply render script src as eval! I don't understand the meaning of these two sentences. Though I'm not a qualified voter I'm probably the one besides Werner who is closest to the MyFaces AJAX code, so I thought I might have a vote on this. Best regards, Ganesh
Re: Myfaces 2.0 PPR ResponseWriter impl
Ganesh schrieb: Hi, So here is my proposal and I am working on it already. Scan for script startElement tags and postpone the rendering of those until the endUpdate or endInsert is issued! Scan for script src and add some dynamic loading code to it (already finished in the javascripts) and postpone it as well! -1 for script scanning on the server side. You will get into serious troubles with this. uff I think you got me wrong here what I propose to do is following writer.startElement(script writer.writeAttribute(src,bla.js should expand into eval![CDATA[ var script = myfaces.utils.loadScript(bla.js); eval(script); ]] /eval nothing fancy with script scanning! I formulated it the wrong way basically! 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. that is a corner case we cannot really cover on writer level, the component author has to take care of it!) The normal case on the component side simply is !-- means that you dont write it out at all but leave it out. I am not talking about page designer level here, but about component writer level. The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! Dont get me wrong, but I have yet to see component code where the author is issuing a !-- instead of just setting an if which does not render anything! 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) Actually the funny thing is this does not cost any performance at all since it is done mostly with linear runtime complexity on the codeside (the evals are concatenated into a stringbuilder and after the end of the insert or update issued as eval section), embedded script parsing has a serious impact on the client side for some browsers (IE I am talking about you), which is the reason why I want to cover this on the server side if possible! 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. If it does we have to investigate why and to the worse simply turn it off, since it is just an extension class to our existing Impl class this is a non issue, but since it does not alter the standard behavior I rather doubt it! eval within an active update or insert also causes the same delay behavior! if non update or insert is issued before then simply render script src as eval! Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case I am not sure what to do with simple issued html elements in this case! I have to test that but I assume the RI either throws an exception or renders buggy output in this case! (This case can happen only if you try to render the ppr cycle from begin to end yourself, otherwise, some parts of the framework have to issue the update automatically) Werner
Re: Myfaces 2.0 PPR ResponseWriter impl
Werner Punz schrieb: Dont get me wrong, but I have yet to see component code where the author is issuing a !-- instead of just setting an if which does not render anything! Ok even that we can cover, but the question is is the coverage of this corner case needed? As I said I have yet to see code which does this :-) Werner
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, -1 for script scanning on the server side. You will get into serious troubles with this. uff I think you got me wrong here what I propose to do is following writer.startElement(script writer.writeAttribute(src,bla.js should expand into eval![CDATA[ var script = myfaces.utils.loadScript(bla.js); eval(script); ]] /eval Yes, you are right, I got you wrong. You were saying We already have this covered in our javascript code by parsing the scripts, but I want to make a switch to have this turned off so I thought you wanted to preprocess all scripts on the server side. If it's only for writeElement/writeAttribute arguments are fewer. 1. You don't know whether the HTML part contains !-- (or some other kind of comment) before the tag that includes the startElement or the script src. that is a corner case we cannot really cover on writer level, the component author has to take care of it!) The normal case on the component side simply is !-- means that you dont write it out at all but leave it out. I am not talking about page designer level here, but about component writer level. The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! I'm talking about !-- on the page level, not on the component level. Facelets will treat !-- as markup. Tags nested inside will still be evaluated. With the writeElement/writeAttribute solution this could end up in script being evaluated though nested inside !-- --. 2. This does cost performance in the server and all the corner cases can be handled on the Javascript side (and already are, as you mentioned in the beginning) Actually the funny thing is this does not cost any performance at all since it is done mostly with linear runtime complexity on the codeside (the evals are concatenated into a stringbuilder and after the end of the insert or update issued as eval section), embedded script parsing has a serious impact on the client side for some browsers (IE I am talking about you), which is the reason why I want to cover this on the server side if possible! Ok, I understand, there is no scanning, just another condition inside writeElement/writeAttribute. 3. By default browsers should do an auto eval when xhr replaces scripts. IE doesn't, but this can be handled on the Javascript side. We shouldn't fix IE bugs in the ResponseWriterImpl. Doing it on the Javascript side only costs performance for browsers that don't support auto eval, the good guys will have a performance benefit. 4. RI doesn't do this kind of stuff. It may even break TCK compatibility. If it does we have to investigate why and to the worse simply turn it off, since it is just an extension class to our existing Impl class this is a non issue, but since it does not alter the standard behavior I rather doubt it! You still modify the markup, this may even alter the page design. Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? I am not sure what to do with simple issued html elements in this case! I have to test that but I assume the RI either throws an exception or renders buggy output in this case! (This case can happen only if you try to render the ppr cycle from begin to end yourself, otherwise, some parts of the framework have to issue the update automatically) Still unclear to me what you are referring to here. Best regards, Ganesh
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi! Not sure if this adds any value to this discussion, but The only question is how facelets handles this case, but I assume faclets simply skips comments and passes it through with out.write! I'm talking about !-- on the page level, not on the component level. Facelets will treat !-- as markup. Tags nested inside will still be evaluated. With the writeElement/writeAttribute solution this could end up in script being evaluated though nested inside !-- --. You can configure this using facelets.SKIP_COMMENTS=true (what we did). Comments are comments then (and skipped) Hopefully mojarra will provide a setting for this too, and, even better, have true as default. Ciao, Mario
Re: Myfaces 2.0 PPR ResponseWriter impl
Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!
Re: Myfaces 2.0 PPR ResponseWriter impl
Hi, Let me summarize the arguments against pushing scripts to the eval section: 1. scripts inside !-- comments would suddenly become executed if facelets.SKIP_COMMENTS is false (which is the Facelets default) 2. omitting scripts within the markup may damage the layout 3. script order gets messed up if scripts rendered via startElement always come last 4. mojarra doesn't do it No pro arguments in sight, I guess ... Best regards, Ganesh Werner Punz schrieb: Ganesh schrieb: Well the corner case is this... If you are outside of an insert or update cycle the problem is following: What do you do with a simple issued script tag, you have to open an eval section in this case What do you want to express with outside of an insert or update cycle ? Following usecase: Someone writes the ppr response directly instead of going through the framework. What do you do in case of startElement(script then do you write it out or do you push it into an automated eval section! My personal guess is, after a second thought, you dont do anything special, you just should interfere with delayed evals in case an insert or update is issued and not finished, but I am not 100% sure!