You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/03/01 11:46:31 UTC
ExtensionFilter: get rid of its buffering
Hi!
Currently I try to get rid of the buffering of the extension filter. (No
code yet, just many many thoughts about it)
First of all: Who says we have to render the <script src= stuff in
html-head?
I tried a short XHTML and checked it on http://validator.w3.org/check -
it didnt complain about it.
A short look in
http://www.w3.org/TR/xhtml11/xhtml11_dtd.html#a_xhtml11_dtd shows
<!-- These elements are neither block nor inline, and can
essentially be used anywhere in the document body.
-->
<!ENTITY % Misc.class
"%Edit.class;
%Script.class;
%Misc.extra;"
>
so this makes me thinking we can get rid of it without any troubles.
So why cant we just render the script in place and are fine with it.
Just the JsValueChangeListener is an exception which know a
"bodyTagEvent" attribute. But I think we can get rid of it and handle
this through the new to come documentBody tag.
There are also other ideas, but I will discuss them after I know why we
can NOT get rid of the script tag in html-head ;-)
Ciao,
Mario
Re: ExtensionFilter: get rid of its buffering
Posted by Martin Marinschek <ma...@gmail.com>.
I really like that idea, Mario!
superb stuff. Nobody of us has thought about this before...
regards,
Martin
On 3/1/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > i'm not sure and have not tested, but AFAIK the
> > <link rel="stylesheet" ..> tags don't work outside html-head.
> >
> This is where the second idea comes in:
>
> We no longer buffer the jsp page, instead we buffer the css. What does
> this mean?
> We render a css link in html-head which looks something like this:
>
> <link rel="stylesheet" type="text/css"
> href="/myfacesExtensionFilter/requestId/combined.css">
>
> A map on the server indexed by an requestId will serve than a dynamic
> css with all the required @import statements.
> The only downside here is that the combined.css cant be cached (it
> changes all over the time) but this is not really a problem as the real
> css are still cacheable by the browser.
>
> I am going to test this out now.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: ExtensionFilter: get rid of its buffering
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> i'm not sure and have not tested, but AFAIK the
> <link rel="stylesheet" ..> tags don't work outside html-head.
>
This is where the second idea comes in:
We no longer buffer the jsp page, instead we buffer the css. What does
this mean?
We render a css link in html-head which looks something like this:
<link rel="stylesheet" type="text/css"
href="/myfacesExtensionFilter/requestId/combined.css">
A map on the server indexed by an requestId will serve than a dynamic
css with all the required @import statements.
The only downside here is that the combined.css cant be cached (it
changes all over the time) but this is not really a problem as the real
css are still cacheable by the browser.
I am going to test this out now.
Ciao,
Mario
Re: ExtensionFilter: get rid of its buffering
Posted by Volker Weber <us...@weber-oldenburg.de>.
Hi,
i'm not sure and have not tested, but AFAIK the
<link rel="stylesheet" ..> tags don't work outside html-head.
Regards,
Volker
Mario Ivankovits wrote:
> Hi!
>
> Currently I try to get rid of the buffering of the extension filter. (No
> code yet, just many many thoughts about it)
>
> First of all: Who says we have to render the <script src= stuff in
> html-head?
>
> I tried a short XHTML and checked it on http://validator.w3.org/check -
> it didnt complain about it.
> A short look in
> http://www.w3.org/TR/xhtml11/xhtml11_dtd.html#a_xhtml11_dtd shows
>
> <!-- These elements are neither block nor inline, and can
> essentially be used anywhere in the document body.
> -->
> <!ENTITY % Misc.class
> "%Edit.class;
> %Script.class;
> %Misc.extra;"
>
>
> so this makes me thinking we can get rid of it without any troubles.
>
> So why cant we just render the script in place and are fine with it.
>
> Just the JsValueChangeListener is an exception which know a
> "bodyTagEvent" attribute. But I think we can get rid of it and handle
> this through the new to come documentBody tag.
>
> There are also other ideas, but I will discuss them after I know why we
> can NOT get rid of the script tag in html-head ;-)
>
> Ciao,
> Mario
>
--
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.
Re: ExtensionFilter: get rid of its buffering
Posted by Martin Marinschek <ma...@gmail.com>.
We have a better way of putting onload stuff in with dojo anyways. So
that bodyTagEvent will go.
regards,
Martin
On 3/1/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Currently I try to get rid of the buffering of the extension filter. (No
> code yet, just many many thoughts about it)
>
> First of all: Who says we have to render the <script src= stuff in
> html-head?
>
> I tried a short XHTML and checked it on http://validator.w3.org/check -
> it didnt complain about it.
> A short look in
> http://www.w3.org/TR/xhtml11/xhtml11_dtd.html#a_xhtml11_dtd shows
>
> <!-- These elements are neither block nor inline, and can
> essentially be used anywhere in the document body.
> -->
> <!ENTITY % Misc.class
> "%Edit.class;
> %Script.class;
> %Misc.extra;"
> >
>
> so this makes me thinking we can get rid of it without any troubles.
>
> So why cant we just render the script in place and are fine with it.
>
> Just the JsValueChangeListener is an exception which know a
> "bodyTagEvent" attribute. But I think we can get rid of it and handle
> this through the new to come documentBody tag.
>
> There are also other ideas, but I will discuss them after I know why we
> can NOT get rid of the script tag in html-head ;-)
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces