Re : Re : Re : Re : f:verbatim question

[Des qsdqsd <de...@yahoo.fr>]

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 <mk...@gmail.com>
À : MyFaces Discussion <us...@myfaces.apache.org>
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 
http://fr.answers.yahoo.com

Re: Re : Re : Re : Re : f:verbatim question

[Mike Kienenberger <mk...@gmail.com>]

On 3/19/07, Des qsdqsd <de...@yahoo.fr> wrote:
> 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 ?

You could write directly to the response stream (or response writer) yourself.

However, that's more or less what outputText already does.

Re: Re : Re : Re : Re : f:verbatim question

[Simon Kitching <si...@rhe.co.nz>]

Mike Kienenberger wrote:
> 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.

Yes, my guess would be the ExtensionFilter too (and in particular the 
ReducedHtmlParser class).

What this filter does is buffer all output generated during the normal 
JSF render, then scan that output looking for interesting locations like 
the end of the [head] section, the start of the [body] section etc. It 
uses this information to inject text into the resulting page (eg script 
tags into the head or onload calls into the body tag).

Putting XML/HTML comments around some of the body would enable the 
ReducedHtmlParser class to quickly skip the content rather than having 
to carefully parse it.

So in short, it looks like ReducedHtmlParser needs some performance 
improvements. Feel free to contribute patches!

Regards,

Simon

Re: Re : Re : Re : Re : f:verbatim question

[Mike Kienenberger <mk...@gmail.com>]

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 <de...@yahoo.fr> 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 <mk...@gmail.com>
> À : MyFaces Discussion <us...@myfaces.apache.org>
> 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.