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

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

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

Myfaces 2.0 PPR ResponseWriter impl

Hello everyone There are some corner cases which are not covered by our current implementation of the ppr response writer. (And neither by the RI as the comments from Salem seem to show) I will give an example PPR Response It usually starts with startUpate on the ppr response writer then

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

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)

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

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 =

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 !--

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 ?

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