If it's not the method, and it's not the browser, (and I'm pretty sure it's not the JSF implementation), then it's probably a filter, most likely the Tomahawk Extensions filter.
Try commenting out this filter and see if it makes a difference. If anything, if it were the JSF implementation, I'd expect escape=true to take longer than escape=false. Escape=true means that it performs html-escaping on everything whereas escape=false means it renders the output as-is. At this point, the most important thing to do is to time the execution of each servlet/servlet-filter involved. It should be pretty easy to create a custom filter which echos the before and after timing values for doFilter(), and then sandwich all of your other filters/servlets between them. You'd just need a way to identify which timing came from which pieces (you could either output the next filter class in the chain or you could pass in a parameter to identify the current timing filter). On 3/19/07, Des qsdqsd <[EMAIL PROTECTED]> wrote:
Thanks for you advices ... Actually, I'm sure the browser is not the problem : getting the page with command line tools (wget) takes the exact same time as requesting it with a browser ... If I put escape=true in the outputText tag : the response is quick but ugly (I can see all html formatting) ... if I put escape=false, then it take forever ... This is why I wonder if the responsible if not the building of all jsf components corresponding to all html ... is there a way to include raw html content inside a jsf page without all the machinery ? ----- Message d'origine ---- De : Mike Kienenberger <[EMAIL PROTECTED]> À : MyFaces Discussion <[email protected]> Envoyé le : Lundi, 19 Mars 2007, 17h13mn 56s Objet : Re: Re : Re : Re : f:verbatim question Sorry, I misunderstood what you wrote -- I didn't realize you were outputting the string in a comment as well. However, unless you've tested with an actual timing filter around your request/response, it still may not be the issue. The issue could be the web browser itself rendering the page (which seems more likely than a JSF issue -- JSF should simply be outputting the raw text stream in both cases). The other potential issue might be the processing of the response via the extensions filter, so that would be another area to have a timing test. ________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.
