You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Manfred Geiler <ma...@apache.org> on 2004/12/01 10:04:04 UTC
Re: SV: Javascript Hell
Sylvain Vieujot wrote:
> On Tue, 2004-11-30 at 17:16 +0100, Manfred Geiler wrote:
>
>>Sylvain,
>>I understand your concerns and I agree that there is already some kind
>>of javascript hell that will become worse.
>>But there are some important issues to consider first:
>>1. There are two kinds of resources
>> a. those a component needs for rendering directly (e.g. images)
>> b. those, that must be referenced in HTML Head (javascript, css)
>>2. Handling resources via Servlet can be implemented fast in a simple
>>way, i.e. getting the Stream for the given name and stream it to the
>>client. But keep in mind that this is not the only thing a
>>sophisticated, performance optimized ResourceServlet must do: think of
>>caching, handling browser HTTP HEAD requests instead of GET, etc.
>>So we should take a look at Tomcats DefaultServlet first, before
>>reinventing the wheel.
>>
>
> You're right, but anyway, I think this is not the difficult part.
>
>>3. The facility method is easy to implement for (1.a.) but difficult to
>>handle for (1.b.). There are two possible solutions:
>> a. To automatically render the link or script tags in the html head
>>only if they are really needed, the whole page rendering must be
>>buffered (difficult, particularly when jsp includes or tiles are used).
>>Inspecting the component tree prior to rendering is no solution because
>>on first page access the component tree is empty!
>> b. The user must configure, which components he is using either
>>globally in web.xml or as attributes to the tag that Hermod mentions.
>>
>
> for 1.b, I agree that they might not be any easy way to render the link
> in the head. But I tried to include script links and css links in the
> body, and it works fine.
> Is there any objection to do this ? It would really make the all thing easy.
> For the <script src="..."></script>, it's definitely allowed to use it
> in the body :
> http://www.w3.org/TR/html401/interact/scripts.html
Yes, only thing to take care of is to not reference a script twice. This
could either be handled by the components themselves or by the facility
method you mentioned.
> For the <link ...> element the specs says that it should go only in the
> head ... BUT the limited tests I did show that it works (I don't know if
> it always works though).
> http://www.w3.org/TR/html401/struct/links.html#h-12.3
> My guess is that it works, but it fails to provide the user with the
> style sheet alternatives. I don't think this is a problem though as the
> style sheets we will include this way are meant for the components, not
> for the whole page display.
>
> What do you think ?
> Can we still do it for style sheets ?
> Is there another way to do it for <link ...> elements or for style sheets ?
Hmmm. This means we would knowingly break HTML 4.01 conformance. I fear,
people will rail against this if they validate the HTML code that is
rendered by MyFaces.
I suggest the following: We always include a css link for every
component on every page. This would be the standard configuration and
since browsers cache css I don't think this would be a performance
problem. To allow MyFaces to automatically include something in the html
head we introduce a new extended tag that the user must include in the
head sections of his JSP. This is the tag that Hermod mentioned.
We could then add expert configuration params that allow to explicitly
disable single components, so that there is no unnecessary link rendered.
Another way is, to not use <link> or <style> at all and only use inline
style attributes. This is what the HtmlTabbedPaneRenderer does. Drawback
is that it is then impossible to alter css for a component without
subclassing the renderer.
WDYT?
> I don't like the solution of asking the user to configure which
> components he is using, as it's quiet inefficient, error prone, and add
> yet another level of complexity.
Yes, agreed, using components should be as easy as possible.
Manfred
>>
>>hermod.opstvedt@dnbnor.no <ma...@dnbnor.no> wrote:
>>> Hi
>>>
>>> Another solution is to add another tag to the lib, which the developer
>>> could add at the top of the page - ala the Struts <html:script> tag.
>>> Making it parameterless so that it could itself find out which librarys
>>> to load
>>> or
>>> add some more fuctionality to the view <f:tag> so that it would render
>>> the <link> stuff.
>>>
>>> Hermod
>>>
>>> -----Opprinnelig melding-----
>>> *Fra:* Sylvain Vieujot [mailto:svieujot@apache.org <ma...@apache.org>]
>>> *Sendt:* 30. november 2004 13:47
>>> *Til:* MyFaces Development
>>> *Emne:* Javascript Hell
>>>
>>> Hello everybody,
>>>
>>> Right now, some components require you to include some javascript
>>> libraries in your app, and to reference those libraries in your
>>> page's header.
>>> Just for your example webapp, the header looks like that :
>>>
>>> <!-- JSCook Menu -->
>>>
>>> <script language="JavaScript" src="jscookmenu/JSCookMenu.js" type="text/javascript"></script>
>>> <script language="JavaScript" src="jscookmenu/ThemeOffice/theme.js"></script>
>>> <link rel="stylesheet" href="jscookmenu/ThemeOffice/theme.css" type="text/css">
>>> <script language="JavaScript" src="jscookmenu/ThemeMiniBlack/theme.js"></script>
>>> <link rel="stylesheet" href="jscookmenu/ThemeMiniBlack/theme.css" type="text/css">
>>> <script language="JavaScript" src="jscookmenu/ThemeIE/theme.js"></script>
>>> <link rel="stylesheet" href="jscookmenu/ThemeIE/theme.css" type="text/css">
>>> <script language="JavaScript" src="jscookmenu/ThemePanel/theme.js"></script>
>>> <link rel="stylesheet" href="jscookmenu/ThemePanel/theme.css" type="text/css">
>>>
>>> <!-- JSCalendar -->
>>> <script language="JavaScript" src="jscalendar/popcalendar.js" type="text/javascript"></script>
>>> <link rel="stylesheet" href="jscalendar/jscalendar-WH/theme.css" type="text/css">
>>> <link rel="stylesheet" href="jscalendar/jscalendar-DB/theme.css" type="text/css">
>>>
>>> <!-- JSPopup -->
>>> <script language="JavaScript" src="jspopup/JSPopup.js" type="text/javascript"></script>
>>>
>>>
>>> I'm now working on a new component that is javascript intensive too,
>>> and that would require the include of at least 5 other .js files.
>>>
>>> I think we should make this transparent to the user by :
>>>
>>> * Including the scripts/css/whatever required in the myfaces.jar
>>> file as resources. So, we are sure we always have the .js
>>> file's version that works, and the developer just needs to
>>> include the myfaces lib. (this will grow a bite the size of
>>> the jar though).
>>> * Have the components load the script/css/whatever in a standard
>>> way so that the page's developer doesn't need to bother, and
>>> so that the script/css/... is only included once in the page.
>>>
>>> So, starting to think about a solution for this, here is my first idea :
>>>
>>> - Have all those scripts/css/... as resources
>>>
>>> - Make an additional servlet that the webapp developper would
>>> include in his web.xml declarations, and that would be invoqued like :
>>> http://my.webserver.com/webapp/myFacesRessource?name=jspopup.js
>>>
>>> This is the only thing the webapp developper would have to do
>>> (declare the servlet), but I don't see how we could avoid that
>>> without writing the scripts/css/... into the page.
>>> Writing the scripts/css/... into the page would be bad for
>>> caching, and wouldn't allow us to use standard images with this
>>> facility.
>>>
>>> - Have a facility so that the component's renderer can call
>>> something like
>>> includeRessourceScriptLibrary(facesContext,"jspopup/JSPopup.js")
>>> (similar helper for css, ...), and the code calling the above
>>> servlet is automatically included in the page.
>>>
>>> Any thoughts on this ?
>>>
>>> Sylvain.
>>>
>>>
>>>
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>
>>> This email with attachments is solely for the use of the individual or
>>> entity to whom it is addressed. Please also be aware that the DnB NOR Group
>>> cannot accept any payment orders or other legally binding correspondence
>>> with
>>> customers as a part of an email.
>>>
>>> This email message has been virus checked by the virus programs used
>>> in the DnB NOR Group.
>>>
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RE: tlddoc error
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Sylvain,
I only have JDK1.4 on my box.
HTH,
Matthias
-----Original Message-----
From: Sylvain Vieujot [mailto:svieujot@apache.org]
Sent: Saturday, December 04, 2004 11:38 PM
To: MyFaces Development
Subject: RE: tlddoc error
Thank you Matthias,
I think it has something to do with my config then.
I'll dig into it.
BTW, did you try it with jdk 1.4 or jdk 1.5 ?
Because I suspect that it is a java 5 issue.
Sylvain.
On Sat, 2004-12-04 at 08:55 +0100, Matthias Wessendorf wrote:
strange,
mine works...
Buildfile:
C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\MyFaces\build\build
.xml
resolve-tld-entities:
[xslt] Transforming into C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\myfaces-tlds
tlddoc:
[java] Loading and translating 1 Tag Library...
[java] Generating docs for MyFaces Extensions...
[java] Documentation generated. If your tag library is intended for
public use,
[java] please add it to the repository at
http://taglibrarydoc.dev.java.net/
BUILD SUCCESSFUL
Total time: 14 seconds
-----Original Message-----
From: Sylvain Vieujot [mailto:svieujot@apache.org]
Sent: Saturday, December 04, 2004 3:20 AM
To: MyFaces Development
Subject: tlddoc error
While trying to build the TLD doc, I get an error :
Buildfile: /home/sylvain/My/Progs/Java/incubator-myfaces/build/build.xml
resolve-tld-entities:
[xslt] Transforming into
/home/sylvain/My/Progs/Java/incubator-myfaces/build/temp/myfaces-tlds
tlddoc:
[java] Loading and translating 1 Tag Library...
[java] com.sun.tlddoc.GeneratorException: Error:
/home/sylvain/My/Progs/Java/incubator-myfaces/build/temp/myfaces-tlds/my
faces_ext.tld does not have <taglib> as root.
[java] at
com.sun.tlddoc.TLDDocGenerator.createTLDSummaryDoc(TLDDocGenerator.java:
546)
[java] at
com.sun.tlddoc.TLDDocGenerator.generate(TLDDocGenerator.java:439)
[java] at com.sun.tlddoc.TLDDoc.main(TLDDoc.java:217)
BUILD SUCCESSFUL
Total time: 4 seconds
And in fact the document has <taglib> as root.
Anybody knows what this is ?
Thanks,
Sylvain.
RE: tlddoc error
Posted by Sylvain Vieujot <sv...@apache.org>.
Thank you Matthias,
I think it has something to do with my config then.
I'll dig into it.
BTW, did you try it with jdk 1.4 or jdk 1.5 ?
Because I suspect that it is a java 5 issue.
Sylvain.
On Sat, 2004-12-04 at 08:55 +0100, Matthias Wessendorf wrote:
> strange,
>
> mine works...
>
>
> Buildfile: C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace
> \MyFaces\build\build.xml
>
> resolve-tld-entities:
>
> [xslt] Transforming into C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\myfaces-
> tlds
>
> tlddoc:
>
> [java] Loading and translating 1 Tag Library...
>
> [java] Generating docs for MyFaces Extensions...
>
> [java] Documentation generated. If your tag library is intended for
> public use,
>
> [java] please add it to the repository at
> http://taglibrarydoc.dev.java.net/
>
> BUILD SUCCESSFUL
>
> Total time: 14 seconds
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Sylvain Vieujot [mailto:svieujot@apache.org]
> Sent: Saturday, December 04, 2004 3:20 AM
> To: MyFaces Development
> Subject: tlddoc error
>
>
> While trying to build the TLD doc, I get an error :
>
> Buildfile: /home/sylvain/My/Progs/Java/incubator-
> myfaces/build/build.xml
> resolve-tld-entities:
> [xslt] Transforming
> into /home/sylvain/My/Progs/Java/incubator-
> myfaces/build/temp/myfaces-tlds
> tlddoc:
> [java] Loading and translating 1 Tag Library...
> [java] com.sun.tlddoc.GeneratorException:
> Error: /home/sylvain/My/Progs/Java/incubator-
> myfaces/build/temp/myfaces-tlds/myfaces_ext.tld does not have
> <taglib> as root.
> [java] at
> com.sun.tlddoc.TLDDocGenerator.createTLDSummaryDoc
> (TLDDocGenerator.java:546)
> [java] at com.sun.tlddoc.TLDDocGenerator.generate
> (TLDDocGenerator.java:439)
> [java] at com.sun.tlddoc.TLDDoc.main(TLDDoc.java:217)
> BUILD SUCCESSFUL
> Total time: 4 seconds
>
> And in fact the document has <taglib> as root.
>
> Anybody knows what this is ?
>
> Thanks,
>
> Sylvain.
RE: tlddoc error
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
strange,
mine works...
Buildfile:
C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\MyFaces\build\build
.xml
resolve-tld-entities:
[xslt] Transforming into C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\myfaces-tlds
tlddoc:
[java] Loading and translating 1 Tag Library...
[java] Generating docs for MyFaces Extensions...
[java] Documentation generated. If your tag library is intended for
public use,
[java] please add it to the repository at
http://taglibrarydoc.dev.java.net/
BUILD SUCCESSFUL
Total time: 14 seconds
-----Original Message-----
From: Sylvain Vieujot [mailto:svieujot@apache.org]
Sent: Saturday, December 04, 2004 3:20 AM
To: MyFaces Development
Subject: tlddoc error
While trying to build the TLD doc, I get an error :
Buildfile: /home/sylvain/My/Progs/Java/incubator-myfaces/build/build.xml
resolve-tld-entities:
[xslt] Transforming into
/home/sylvain/My/Progs/Java/incubator-myfaces/build/temp/myfaces-tlds
tlddoc:
[java] Loading and translating 1 Tag Library...
[java] com.sun.tlddoc.GeneratorException: Error:
/home/sylvain/My/Progs/Java/incubator-myfaces/build/temp/myfaces-tlds/my
faces_ext.tld does not have <taglib> as root.
[java] at
com.sun.tlddoc.TLDDocGenerator.createTLDSummaryDoc(TLDDocGenerator.java:
546)
[java] at
com.sun.tlddoc.TLDDocGenerator.generate(TLDDocGenerator.java:439)
[java] at com.sun.tlddoc.TLDDoc.main(TLDDoc.java:217)
BUILD SUCCESSFUL
Total time: 4 seconds
And in fact the document has <taglib> as root.
Anybody knows what this is ?
Thanks,
Sylvain.
tlddoc error
Posted by Sylvain Vieujot <sv...@apache.org>.
While trying to build the TLD doc, I get an error :
Buildfile: /home/sylvain/My/Progs/Java/incubator-myfaces/build/build.xml
resolve-tld-entities:
[xslt] Transforming into /home/sylvain/My/Progs/Java/incubator-
myfaces/build/temp/myfaces-tlds
tlddoc:
[java] Loading and translating 1 Tag Library...
[java] com.sun.tlddoc.GeneratorException:
Error: /home/sylvain/My/Progs/Java/incubator-myfaces/build/temp/myfaces-
tlds/myfaces_ext.tld does not have <taglib> as root.
[java] at com.sun.tlddoc.TLDDocGenerator.createTLDSummaryDoc
(TLDDocGenerator.java:546)
[java] at com.sun.tlddoc.TLDDocGenerator.generate
(TLDDocGenerator.java:439)
[java] at com.sun.tlddoc.TLDDoc.main(TLDDoc.java:217)
BUILD SUCCESSFUL
Total time: 4 seconds
And in fact the document has <taglib> as root.
Anybody knows what this is ?
Thanks,
Sylvain.
RE: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Well, yes, sorry String.contains( xxx ) is java 1.5
I replace is right now.
Sorry for that,
Sylvain.
On Thu, 2004-12-02 at 12:09 +0100, Matthias Wessendorf wrote:
> Hi Sylvain,
>
> I just updated my *local* MyFaces-code-base.
>
> On compiling I got this message:
>
> [javac] Compiling 13 source files to C:\DOKUME~1\ADMINI~1\LOKALE~1
> \Temp\myfaces-components\classes
>
> [javac] C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\MyFaces
> \src\components\org\apache\myfaces\component\html\util
> \AddResource.java:149: cannot resolve symbol
>
> [javac] symbol : method contains (java.lang.String)
>
> [javac] location: class java.lang.String
>
> [javac] return request.getRequestURI().contains
> ( RESOURCE_VIRUAL_PATH );
>
> [javac] ^
>
> [javac] 1 error
>
>
>
> Am I missing something`?
>
> No idea right now..
>
> Thanks!
>
RE: SV: Javascript Hell
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
Hi Sylvain,
I just updated my *local* MyFaces-code-base.
On compiling I got this message:
[javac] Compiling 13 source files to
C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\myfaces-components\classes
[javac]
C:\Programme\eclipse-SDK-3.0-win32\eclipse\workspace\MyFaces\src\compone
nts\org\apache\myfaces\component\html\util\AddResource.java:149: cannot
resolve symbol
[javac] symbol : method contains (java.lang.String)
[javac] location: class java.lang.String
[javac] return request.getRequestURI().contains( RESOURCE_VIRUAL_PATH );
[javac] ^
[javac] 1 error
Am I missing something`?
No idea right now..
Thanks!
Re: Commun error on restoring submitted values
Posted by Martin Marinschek <ma...@gmail.com>.
thanks for the info,
did you already correct the bug in the calendar renderer?
regards,
Martin
On Thu, 09 Dec 2004 01:09:41 -0400, Sylvain Vieujot <sv...@apache.org> wrote:
> While playing with the htmlEditor component, I found that if a page is only
> refreshed (like when you click on a tab of an x:panelTab), then the
> submitted value was lost, and replaced with the component's backing bean
> value.
> The reason, for that is that I was using a code like this in the renderer :
>
> String textToRender = uiComponent.getValue();
>
> Doing this, the textToRender is always the same until the form is
> validated, and the Update Model Values phase is run. And any intermediary
> rendering will just reset the data entered by the user.
> A better code would be :
>
> String textToRender = uiComponent.getSubmittedValue()!=null ?
> uiComponent.getSubmittedValue() : uiComponent.getValue();
>
> For a really correct code, look at the following helper function in :
> org.apache.myfaces.renderkit.RendererUtils.getStringValue
>
> I'm sending this email to the mailing list because it is quite easy to fall
> for this bug, and I think I've already found 2 places in the extensions
> renderers where we have this bug : in the calendar renderer, and in the date
> renderer.
> I've marked the places in the sources where I think is the bug, but we
> might find other occurrences.
>
> Sylvain.
Commun error on restoring submitted values
Posted by Sylvain Vieujot <sv...@apache.org>.
While playing with the htmlEditor component, I found that if a page is
only refreshed (like when you click on a tab of an x:panelTab), then the
submitted value was lost, and replaced with the component's backing bean
value.
The reason, for that is that I was using a code like this in the
renderer :
String textToRender = uiComponent.getValue();
Doing this, the textToRender is always the same until the form is
validated, and the Update Model Values phase is run. And any
intermediary rendering will just reset the data entered by the user.
A better code would be :
String textToRender = uiComponent.getSubmittedValue()!=null ?
uiComponent.getSubmittedValue() : uiComponent.getValue();
For a really correct code, look at the following helper function in :
org.apache.myfaces.renderkit.RendererUtils.getStringValue
I'm sending this email to the mailing list because it is quite easy to
fall for this bug, and I think I've already found 2 places in the
extensions renderers where we have this bug : in the calendar renderer,
and in the date renderer.
I've marked the places in the sources where I think is the bug, but we
might find other occurrences.
Sylvain.
Re: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Oliver,
Thanks for your modifications !
I always have problems with i8n :-(
I kept your speed improvements for the <head> body detection, but I
search for head and HEAD before looking for the body, as if there is one
head, we should really put the links there.
I made another change to the filter to be able to handle resource
hierarchies.
That is, if you give a script the base URL for the resources, let's say
blabla/images, then it'll be able to fetch everything bellow it :
blabla/images/theme1/a.gif, ...
This is quite important as this enabled true transparent delivery, even
when the resources are in the jar.
I use it quite heavily in a a new component I hope to commit by the end
of the week and that has tens of scripts/images, ... (it's an
HtmlEditor).
This can only be done using a filter, and you can't use resources
hierarchies with a servlet because of the way to pass the parameters
(you'll see, I changed that in my last post).
A downside though is that now, we have to add the /faces/* mapping to
the ExtensionsFilter. That is, if you use the *.jsf scheme, the filter
will need to have both mappings.
I write that in bold, as this is a modification you shouldn't forget in
your applications.
Nevertheless, I think this downside is worth the pain.
I understand your worry for the caching of the resources.
Indeed, right now, the resources aren't cached.
I plan to add a parameter to the filter that would be the delay to cache
the resources.
The filter will set an optional Expires to the response, to improve the
caching.
It's not a perfect solution, but I used it in some projects, and once
you've accepted the fact that it's not ideal, it turn out to be quite
convenient.
I just use a delay of 0 on the development servers, and 3 days on the
production servers.
For the split of the filter (multipart handling vs resource delivery),
I'm not a great fan of this idea.
If you look at the code of the filter itself, you'll see that it's
pretty clean, and quite light.
Also, a multipart request might need to have it's response altered by
the resource delivery script if the form as components with resources.
So, we would in any case need the 2 filters.
In the end, I find that more complex for the user AND for the developer
(us).
I find the current solution quite clean and simple to understand /
implement for any MyFaces newbie.
Thanks for your help, and sorry for this long email.
Sylvain.
On Thu, 2004-12-02 at 02:09 +0100, Oliver Rossmueller wrote:
> Sylvain,
>
> I was very interested in what you have done and had a look at your
> enhancements and it's cool stuff! Anyway I committed some modifications
> because of i18n issues and (hopefully) to improve performance a little
> bit. And there are two points I would like to discuss:
>
> 1) IMHO resource delivery and multipart handling should not be mixed up
> in one filter. I understand your intentions to keep configuration simple
> but serving embedded javascript and css resources has nothing in common
> with multipart requests so we should keep these two aspects separated.
> It think we can ask our users to add an additional servlet filter to
> their web.xml for the benefit of simplified JSP and a simplified
> packaging process.
>
> 2) I would move resource delivery from the filter to a servlet so the
> filter just has to wrap the response object and perform the
> post-processing of the response. The advantage of a servlet-based
> solution is reduced server load. If getLastModified() is implemented in
> a usefull manner we don't have to stream a resource again if the browser
> already has the latest version. Another servlet would require for
> another servlet and servlet-mapping entry in web.xml, but again the
> benefit should be worth the effort to any user.
>
> So what do you think?
>
> Oliver
>
>
> Sylvain Vieujot wrote:
>
> > Yes, that's exactly what I'm doing.
> > When the code is comited, please review it though, because I'm not
> > sure I'm 100% correct in the setContentType, and all the i8n stuffs.
> >
> > Sylvain.
> >
> > On Wed, 2004-12-01 at 19:29 +0100, Manfred Geiler wrote:
> >
> >>Sylvain Vieujot wrote:
> >>> Ok, it works fine for the javascripts with the new filter.
> >>>
> >>> For the CSS, I'm working on a solution "a la SiteMesh" (
> >>> http://www.opensymphony.com/sitemesh/ ).
> >>> This means in the filter, we capture the response, and before rendering
> >>> it, we include the relevant <link>, ... in the header.
> >>
> >>You could even wrap the response and redirect the standard response
> >>Writer through a special Writer, that includes the relevant <link> tags
> >>into the stream, before actually streaming it back to the client.
> >>
> >>> As SiteMesh is known to have quite good performance, I think it's an
> >>> acceptable solution.
> >>>
> >>> Any thoughts on this approach ?
> >>
> >>Cool solution, yes of course!
> >>
> >>Manfred
> >>
> >>
>
Re: SV: Javascript Hell
Posted by Oliver Rossmueller <ol...@tuxerra.com>.
Sylvain,
I was very interested in what you have done and had a look at your
enhancements and it's cool stuff! Anyway I committed some modifications
because of i18n issues and (hopefully) to improve performance a little
bit. And there are two points I would like to discuss:
1) IMHO resource delivery and multipart handling should not be mixed up
in one filter. I understand your intentions to keep configuration simple
but serving embedded javascript and css resources has nothing in common
with multipart requests so we should keep these two aspects separated.
It think we can ask our users to add an additional servlet filter to
their web.xml for the benefit of simplified JSP and a simplified
packaging process.
2) I would move resource delivery from the filter to a servlet so the
filter just has to wrap the response object and perform the
post-processing of the response. The advantage of a servlet-based
solution is reduced server load. If getLastModified() is implemented in
a usefull manner we don't have to stream a resource again if the browser
already has the latest version. Another servlet would require for
another servlet and servlet-mapping entry in web.xml, but again the
benefit should be worth the effort to any user.
So what do you think?
Oliver
Sylvain Vieujot wrote:
> Yes, that's exactly what I'm doing.
> When the code is comited, please review it though, because I'm not
> sure I'm 100% correct in the setContentType, and all the i8n stuffs.
>
> Sylvain.
>
> On Wed, 2004-12-01 at 19:29 +0100, Manfred Geiler wrote:
>
>>Sylvain Vieujot wrote:
>>> Ok, it works fine for the javascripts with the new filter.
>>>
>>> For the CSS, I'm working on a solution "a la SiteMesh" (
>>> http://www.opensymphony.com/sitemesh/ ).
>>> This means in the filter, we capture the response, and before rendering
>>> it, we include the relevant <link>, ... in the header.
>>
>>You could even wrap the response and redirect the standard response
>>Writer through a special Writer, that includes the relevant <link> tags
>>into the stream, before actually streaming it back to the client.
>>
>>> As SiteMesh is known to have quite good performance, I think it's an
>>> acceptable solution.
>>>
>>> Any thoughts on this approach ?
>>
>>Cool solution, yes of course!
>>
>>Manfred
>>
>>
--
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com
Re: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Yes, that's exactly what I'm doing.
When the code is comited, please review it though, because I'm not sure
I'm 100% correct in the setContentType, and all the i8n stuffs.
Sylvain.
On Wed, 2004-12-01 at 19:29 +0100, Manfred Geiler wrote:
> Sylvain Vieujot wrote:
> > Ok, it works fine for the javascripts with the new filter.
> >
> > For the CSS, I'm working on a solution "a la SiteMesh" (
> > http://www.opensymphony.com/sitemesh/ ).
> > This means in the filter, we capture the response, and before rendering
> > it, we include the relevant <link>, ... in the header.
>
> You could even wrap the response and redirect the standard response
> Writer through a special Writer, that includes the relevant <link> tags
> into the stream, before actually streaming it back to the client.
>
> > As SiteMesh is known to have quite good performance, I think it's an
> > acceptable solution.
> >
> > Any thoughts on this approach ?
>
> Cool solution, yes of course!
>
> Manfred
Re: SV: Javascript Hell
Posted by Manfred Geiler <ma...@apache.org>.
Sylvain Vieujot wrote:
> Ok, it works fine for the javascripts with the new filter.
>
> For the CSS, I'm working on a solution "a la SiteMesh" (
> http://www.opensymphony.com/sitemesh/ ).
> This means in the filter, we capture the response, and before rendering
> it, we include the relevant <link>, ... in the header.
You could even wrap the response and redirect the standard response
Writer through a special Writer, that includes the relevant <link> tags
into the stream, before actually streaming it back to the client.
> As SiteMesh is known to have quite good performance, I think it's an
> acceptable solution.
>
> Any thoughts on this approach ?
Cool solution, yes of course!
Manfred
Re: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Ok, it works fine for the javascripts with the new filter.
For the CSS, I'm working on a solution "a la
SiteMesh" ( http://www.opensymphony.com/sitemesh/ ).
This means in the filter, we capture the response, and before rendering
it, we include the relevant <link>, ... in the header.
As SiteMesh is known to have quite good performance, I think it's an
acceptable solution.
Any thoughts on this approach ?
Sylvain.
Re: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Manfred,
I'll look at it, but I don't think this would work because sometime
(most of the time for me), the JSF part of the page is just a section of
the body.
In starting to implement the Servlet we talked about, I found another
way that I find better :
Today, we have a Multipart filter for the x:fileUpload.
As we have to declare this filter in the web.xml, I'm generalizing this
filter so that it does the Multipart thing, and serves the resources.
Also, the a filter is better than a servlet, because if we use a
servlet, we have to know it's path in advance, whereas for a filter, we
don't need to add a predefined path to the web.xml.
The name I choose for this filter is :
org.apache.myfaces.component.html.util.ExtensionsFilter
Then, in the doc, we just need to say that to use MyFaces with the
extensions, the above ExtensionsFilter needs to be referenced in the
web.xml
At least, I think this will solve the <script> problem.
I'll work on the CSS part right after (if I can find something).
Sylvain.
On Wed, 2004-12-01 at 14:09 +0100, Manfred Geiler wrote:
> Sylvain,
> I probably found a smarter solution for the "render something in html
> header afterwards" problem. It's the same problem as the afterwards
> rendering of hidden input values for client side state saving. So, the
> statement "the whole page rendering must be buffered (difficult..." is
> already an issue.
> Have a look at the ViewTag. It uses a buffered body if client state
> saving is enabled. Components that render state info, do this by calling
> the StateHandler, which renders temporary tokens. The doAfterBody method
> in ViewTag finally replaces these tokens by the actual state info.
> There are still some issues to discuss (buffered body necessary also for
> server state saving, etc.), so please be careful when modifying the
> ViewTag or any other "deep implementation" class.
>
> Manfred
>
>
>
> Sylvain Vieujot wrote:
> > I'll try to do the Servlet to handle the script case at least, and I'll
> > apply it to the popup component, which is one of the simplest case.
> > I think we will find a nice solution for CSS along the road.
> >
> > Breaking HTML 4 conformance isn't fine, but I don't like either the
> > solution to add a mandatory tag in the head.
> > Indeed, sometime, it's convenient to use jsf only to a section of a
> > page, and let jsp handle the rest (including the head).
> > Also, it requires yet another step to use the component, and I really
> > would like to avoid that.
> >
> > Sylvain.
> >
> > On Wed, 2004-12-01 at 10:04 +0100, Manfred Geiler wrote:
> >
> >>Sylvain Vieujot wrote:
> >>> On Tue, 2004-11-30 at 17:16 +0100, Manfred Geiler wrote:
> >>>
> >>>>Sylvain,
> >>>>I understand your concerns and I agree that there is already some kind
> >>>>of javascript hell that will become worse.
> >>>>But there are some important issues to consider first:
> >>>>1. There are two kinds of resources
> >>>> a. those a component needs for rendering directly (e.g. images)
> >>>> b. those, that must be referenced in HTML Head (javascript, css)
> >>>>2. Handling resources via Servlet can be implemented fast in a simple
> >>>>way, i.e. getting the Stream for the given name and stream it to the
> >>>>client. But keep in mind that this is not the only thing a
> >>>>sophisticated, performance optimized ResourceServlet must do: think of
> >>>>caching, handling browser HTTP HEAD requests instead of GET, etc.
> >>>>So we should take a look at Tomcats DefaultServlet first, before
> >>>>reinventing the wheel.
> >>>>
> >>>
> >>> You're right, but anyway, I think this is not the difficult part.
> >>>
> >>>>3. The facility method is easy to implement for (1.a.) but difficult to
> >>>>handle for (1.b.). There are two possible solutions:
> >>>> a. To automatically render the link or script tags in the html head
> >>>>only if they are really needed, the whole page rendering must be
> >>>>buffered (difficult, particularly when jsp includes or tiles are used).
> >>>>Inspecting the component tree prior to rendering is no solution because
> >>>>on first page access the component tree is empty!
> >>>> b. The user must configure, which components he is using either
> >>>>globally in web.xml or as attributes to the tag that Hermod mentions.
> >>>>
> >>>
> >>> for 1.b, I agree that they might not be any easy way to render the link
> >>> in the head. But I tried to include script links and css links in the
> >>> body, and it works fine.
> >>> Is there any objection to do this ? It would really make the all thing easy.
> >>> For the <script src="..."></script>, it's definitely allowed to use it
> >>> in the body :
> >>> http://www.w3.org/TR/html401/interact/scripts.html
> >>
> >>Yes, only thing to take care of is to not reference a script twice. This
> >>could either be handled by the components themselves or by the facility
> >>method you mentioned.
> >>
> >>
> >>> For the <link ...> element the specs says that it should go only in the
> >>> head ... BUT the limited tests I did show that it works (I don't know if
> >>> it always works though).
> >>> http://www.w3.org/TR/html401/struct/links.html#h-12.3
> >>> My guess is that it works, but it fails to provide the user with the
> >>> style sheet alternatives. I don't think this is a problem though as the
> >>> style sheets we will include this way are meant for the components, not
> >>> for the whole page display.
> >>>
> >>> What do you think ?
> >>> Can we still do it for style sheets ?
> >>> Is there another way to do it for <link ...> elements or for style sheets ?
> >>
> >>Hmmm. This means we would knowingly break HTML 4.01 conformance. I fear,
> >>people will rail against this if they validate the HTML code that is
> >>rendered by MyFaces.
> >>I suggest the following: We always include a css link for every
> >>component on every page. This would be the standard configuration and
> >>since browsers cache css I don't think this would be a performance
> >>problem. To allow MyFaces to automatically include something in the html
> >>head we introduce a new extended tag that the user must include in the
> >>head sections of his JSP. This is the tag that Hermod mentioned.
> >>We could then add expert configuration params that allow to explicitly
> >>disable single components, so that there is no unnecessary link rendered.
> >>Another way is, to not use <link> or <style> at all and only use inline
> >>style attributes. This is what the HtmlTabbedPaneRenderer does. Drawback
> >>is that it is then impossible to alter css for a component without
> >>subclassing the renderer.
> >>
> >>WDYT?
> >>
> >>
> >>> I don't like the solution of asking the user to configure which
> >>> components he is using, as it's quiet inefficient, error prone, and add
> >>> yet another level of complexity.
> >>
> >>Yes, agreed, using components should be as easy as possible.
> >>
> >>
> >>Manfred
> >>
> >>
> >>
> >>
> >>>>
> >>>>hermod.opstvedt@dnbnor.no <ma...@dnbnor.no> <mailto:hermod.opstvedt@dnbnor.no <ma...@dnbnor.no>> wrote:
> >>>>> Hi
> >>>>>
> >>>>> Another solution is to add another tag to the lib, which the developer
> >>>>> could add at the top of the page - ala the Struts <html:script> tag.
> >>>>> Making it parameterless so that it could itself find out which librarys
> >>>>> to load
> >>>>> or
> >>>>> add some more fuctionality to the view <f:tag> so that it would render
> >>>>> the <link> stuff.
> >>>>>
> >>>>> Hermod
> >>>>>
> >>>>> -----Opprinnelig melding-----
> >>>>> *Fra:* Sylvain Vieujot [mailto:svieujot@apache.org <ma...@apache.org> <mailto:svieujot@apache.org <ma...@apache.org>>]
> >>>>> *Sendt:* 30. november 2004 13:47
> >>>>> *Til:* MyFaces Development
> >>>>> *Emne:* Javascript Hell
> >>>>>
> >>>>> Hello everybody,
> >>>>>
> >>>>> Right now, some components require you to include some javascript
> >>>>> libraries in your app, and to reference those libraries in your
> >>>>> page's header.
> >>>>> Just for your example webapp, the header looks like that :
> >>>>>
> >>>>> <!-- JSCook Menu -->
> >>>>>
> >>>>> <script language="JavaScript" src="jscookmenu/JSCookMenu.js" type="text/javascript"></script>
> >>>>> <script language="JavaScript" src="jscookmenu/ThemeOffice/theme.js"></script>
> >>>>> <link rel="stylesheet" href="jscookmenu/ThemeOffice/theme.css" type="text/css">
> >>>>> <script language="JavaScript" src="jscookmenu/ThemeMiniBlack/theme.js"></script>
> >>>>> <link rel="stylesheet" href="jscookmenu/ThemeMiniBlack/theme.css" type="text/css">
> >>>>> <script language="JavaScript" src="jscookmenu/ThemeIE/theme.js"></script>
> >>>>> <link rel="stylesheet" href="jscookmenu/ThemeIE/theme.css" type="text/css">
> >>>>> <script language="JavaScript" src="jscookmenu/ThemePanel/theme.js"></script>
> >>>>> <link rel="stylesheet" href="jscookmenu/ThemePanel/theme.css" type="text/css">
> >>>>>
> >>>>> <!-- JSCalendar -->
> >>>>> <script language="JavaScript" src="jscalendar/popcalendar.js" type="text/javascript"></script>
> >>>>> <link rel="stylesheet" href="jscalendar/jscalendar-WH/theme.css" type="text/css">
> >>>>> <link rel="stylesheet" href="jscalendar/jscalendar-DB/theme.css" type="text/css">
> >>>>>
> >>>>> <!-- JSPopup -->
> >>>>> <script language="JavaScript" src="jspopup/JSPopup.js" type="text/javascript"></script>
> >>>>>
> >>>>>
> >>>>> I'm now working on a new component that is javascript intensive too,
> >>>>> and that would require the include of at least 5 other .js files.
> >>>>>
> >>>>> I think we should make this transparent to the user by :
> >>>>>
> >>>>> * Including the scripts/css/whatever required in the myfaces.jar
> >>>>> file as resources. So, we are sure we always have the .js
> >>>>> file's version that works, and the developer just needs to
> >>>>> include the myfaces lib. (this will grow a bite the size of
> >>>>> the jar though).
> >>>>> * Have the components load the script/css/whatever in a standard
> >>>>> way so that the page's developer doesn't need to bother, and
> >>>>> so that the script/css/... is only included once in the page.
> >>>>>
> >>>>> So, starting to think about a solution for this, here is my first idea :
> >>>>>
> >>>>> - Have all those scripts/css/... as resources
> >>>>>
> >>>>> - Make an additional servlet that the webapp developper would
> >>>>> include in his web.xml declarations, and that would be invoqued like :
> >>>>> http://my.webserver.com/webapp/myFacesRessource?name=jspopup.js
> >>>>>
> >>>>> This is the only thing the webapp developper would have to do
> >>>>> (declare the servlet), but I don't see how we could avoid that
> >>>>> without writing the scripts/css/... into the page.
> >>>>> Writing the scripts/css/... into the page would be bad for
> >>>>> caching, and wouldn't allow us to use standard images with this
> >>>>> facility.
> >>>>>
> >>>>> - Have a facility so that the component's renderer can call
> >>>>> something like
> >>>>> includeRessourceScriptLibrary(facesContext,"jspopup/JSPopup.js")
> >>>>> (similar helper for css, ...), and the code calling the above
> >>>>> servlet is automatically included in the page.
> >>>>>
> >>>>> Any thoughts on this ?
> >>>>>
> >>>>> Sylvain.
> >>>>>
> >>>>>
> >>>>>
> >>>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >>>>>
> >>>>> This email with attachments is solely for the use of the individual or
> >>>>> entity to whom it is addressed. Please also be aware that the DnB NOR Group
> >>>>> cannot accept any payment orders or other legally binding correspondence
> >>>>> with
> >>>>> customers as a part of an email.
> >>>>>
> >>>>> This email message has been virus checked by the virus programs used
> >>>>> in the DnB NOR Group.
> >>>>>
> >>>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >>
> >
Re: SV: Javascript Hell
Posted by Manfred Geiler <ma...@apache.org>.
Sylvain,
I probably found a smarter solution for the "render something in html
header afterwards" problem. It's the same problem as the afterwards
rendering of hidden input values for client side state saving. So, the
statement "the whole page rendering must be buffered (difficult..." is
already an issue.
Have a look at the ViewTag. It uses a buffered body if client state
saving is enabled. Components that render state info, do this by calling
the StateHandler, which renders temporary tokens. The doAfterBody method
in ViewTag finally replaces these tokens by the actual state info.
There are still some issues to discuss (buffered body necessary also for
server state saving, etc.), so please be careful when modifying the
ViewTag or any other "deep implementation" class.
Manfred
Sylvain Vieujot wrote:
> I'll try to do the Servlet to handle the script case at least, and I'll
> apply it to the popup component, which is one of the simplest case.
> I think we will find a nice solution for CSS along the road.
>
> Breaking HTML 4 conformance isn't fine, but I don't like either the
> solution to add a mandatory tag in the head.
> Indeed, sometime, it's convenient to use jsf only to a section of a
> page, and let jsp handle the rest (including the head).
> Also, it requires yet another step to use the component, and I really
> would like to avoid that.
>
> Sylvain.
>
> On Wed, 2004-12-01 at 10:04 +0100, Manfred Geiler wrote:
>
>>Sylvain Vieujot wrote:
>>> On Tue, 2004-11-30 at 17:16 +0100, Manfred Geiler wrote:
>>>
>>>>Sylvain,
>>>>I understand your concerns and I agree that there is already some kind
>>>>of javascript hell that will become worse.
>>>>But there are some important issues to consider first:
>>>>1. There are two kinds of resources
>>>> a. those a component needs for rendering directly (e.g. images)
>>>> b. those, that must be referenced in HTML Head (javascript, css)
>>>>2. Handling resources via Servlet can be implemented fast in a simple
>>>>way, i.e. getting the Stream for the given name and stream it to the
>>>>client. But keep in mind that this is not the only thing a
>>>>sophisticated, performance optimized ResourceServlet must do: think of
>>>>caching, handling browser HTTP HEAD requests instead of GET, etc.
>>>>So we should take a look at Tomcats DefaultServlet first, before
>>>>reinventing the wheel.
>>>>
>>>
>>> You're right, but anyway, I think this is not the difficult part.
>>>
>>>>3. The facility method is easy to implement for (1.a.) but difficult to
>>>>handle for (1.b.). There are two possible solutions:
>>>> a. To automatically render the link or script tags in the html head
>>>>only if they are really needed, the whole page rendering must be
>>>>buffered (difficult, particularly when jsp includes or tiles are used).
>>>>Inspecting the component tree prior to rendering is no solution because
>>>>on first page access the component tree is empty!
>>>> b. The user must configure, which components he is using either
>>>>globally in web.xml or as attributes to the tag that Hermod mentions.
>>>>
>>>
>>> for 1.b, I agree that they might not be any easy way to render the link
>>> in the head. But I tried to include script links and css links in the
>>> body, and it works fine.
>>> Is there any objection to do this ? It would really make the all thing easy.
>>> For the <script src="..."></script>, it's definitely allowed to use it
>>> in the body :
>>> http://www.w3.org/TR/html401/interact/scripts.html
>>
>>Yes, only thing to take care of is to not reference a script twice. This
>>could either be handled by the components themselves or by the facility
>>method you mentioned.
>>
>>
>>> For the <link ...> element the specs says that it should go only in the
>>> head ... BUT the limited tests I did show that it works (I don't know if
>>> it always works though).
>>> http://www.w3.org/TR/html401/struct/links.html#h-12.3
>>> My guess is that it works, but it fails to provide the user with the
>>> style sheet alternatives. I don't think this is a problem though as the
>>> style sheets we will include this way are meant for the components, not
>>> for the whole page display.
>>>
>>> What do you think ?
>>> Can we still do it for style sheets ?
>>> Is there another way to do it for <link ...> elements or for style sheets ?
>>
>>Hmmm. This means we would knowingly break HTML 4.01 conformance. I fear,
>>people will rail against this if they validate the HTML code that is
>>rendered by MyFaces.
>>I suggest the following: We always include a css link for every
>>component on every page. This would be the standard configuration and
>>since browsers cache css I don't think this would be a performance
>>problem. To allow MyFaces to automatically include something in the html
>>head we introduce a new extended tag that the user must include in the
>>head sections of his JSP. This is the tag that Hermod mentioned.
>>We could then add expert configuration params that allow to explicitly
>>disable single components, so that there is no unnecessary link rendered.
>>Another way is, to not use <link> or <style> at all and only use inline
>>style attributes. This is what the HtmlTabbedPaneRenderer does. Drawback
>>is that it is then impossible to alter css for a component without
>>subclassing the renderer.
>>
>>WDYT?
>>
>>
>>> I don't like the solution of asking the user to configure which
>>> components he is using, as it's quiet inefficient, error prone, and add
>>> yet another level of complexity.
>>
>>Yes, agreed, using components should be as easy as possible.
>>
>>
>>Manfred
>>
>>
>>
>>
>>>>
>>>>hermod.opstvedt@dnbnor.no <ma...@dnbnor.no> <mailto:hermod.opstvedt@dnbnor.no <ma...@dnbnor.no>> wrote:
>>>>> Hi
>>>>>
>>>>> Another solution is to add another tag to the lib, which the developer
>>>>> could add at the top of the page - ala the Struts <html:script> tag.
>>>>> Making it parameterless so that it could itself find out which librarys
>>>>> to load
>>>>> or
>>>>> add some more fuctionality to the view <f:tag> so that it would render
>>>>> the <link> stuff.
>>>>>
>>>>> Hermod
>>>>>
>>>>> -----Opprinnelig melding-----
>>>>> *Fra:* Sylvain Vieujot [mailto:svieujot@apache.org <ma...@apache.org> <mailto:svieujot@apache.org <ma...@apache.org>>]
>>>>> *Sendt:* 30. november 2004 13:47
>>>>> *Til:* MyFaces Development
>>>>> *Emne:* Javascript Hell
>>>>>
>>>>> Hello everybody,
>>>>>
>>>>> Right now, some components require you to include some javascript
>>>>> libraries in your app, and to reference those libraries in your
>>>>> page's header.
>>>>> Just for your example webapp, the header looks like that :
>>>>>
>>>>> <!-- JSCook Menu -->
>>>>>
>>>>> <script language="JavaScript" src="jscookmenu/JSCookMenu.js" type="text/javascript"></script>
>>>>> <script language="JavaScript" src="jscookmenu/ThemeOffice/theme.js"></script>
>>>>> <link rel="stylesheet" href="jscookmenu/ThemeOffice/theme.css" type="text/css">
>>>>> <script language="JavaScript" src="jscookmenu/ThemeMiniBlack/theme.js"></script>
>>>>> <link rel="stylesheet" href="jscookmenu/ThemeMiniBlack/theme.css" type="text/css">
>>>>> <script language="JavaScript" src="jscookmenu/ThemeIE/theme.js"></script>
>>>>> <link rel="stylesheet" href="jscookmenu/ThemeIE/theme.css" type="text/css">
>>>>> <script language="JavaScript" src="jscookmenu/ThemePanel/theme.js"></script>
>>>>> <link rel="stylesheet" href="jscookmenu/ThemePanel/theme.css" type="text/css">
>>>>>
>>>>> <!-- JSCalendar -->
>>>>> <script language="JavaScript" src="jscalendar/popcalendar.js" type="text/javascript"></script>
>>>>> <link rel="stylesheet" href="jscalendar/jscalendar-WH/theme.css" type="text/css">
>>>>> <link rel="stylesheet" href="jscalendar/jscalendar-DB/theme.css" type="text/css">
>>>>>
>>>>> <!-- JSPopup -->
>>>>> <script language="JavaScript" src="jspopup/JSPopup.js" type="text/javascript"></script>
>>>>>
>>>>>
>>>>> I'm now working on a new component that is javascript intensive too,
>>>>> and that would require the include of at least 5 other .js files.
>>>>>
>>>>> I think we should make this transparent to the user by :
>>>>>
>>>>> * Including the scripts/css/whatever required in the myfaces.jar
>>>>> file as resources. So, we are sure we always have the .js
>>>>> file's version that works, and the developer just needs to
>>>>> include the myfaces lib. (this will grow a bite the size of
>>>>> the jar though).
>>>>> * Have the components load the script/css/whatever in a standard
>>>>> way so that the page's developer doesn't need to bother, and
>>>>> so that the script/css/... is only included once in the page.
>>>>>
>>>>> So, starting to think about a solution for this, here is my first idea :
>>>>>
>>>>> - Have all those scripts/css/... as resources
>>>>>
>>>>> - Make an additional servlet that the webapp developper would
>>>>> include in his web.xml declarations, and that would be invoqued like :
>>>>> http://my.webserver.com/webapp/myFacesRessource?name=jspopup.js
>>>>>
>>>>> This is the only thing the webapp developper would have to do
>>>>> (declare the servlet), but I don't see how we could avoid that
>>>>> without writing the scripts/css/... into the page.
>>>>> Writing the scripts/css/... into the page would be bad for
>>>>> caching, and wouldn't allow us to use standard images with this
>>>>> facility.
>>>>>
>>>>> - Have a facility so that the component's renderer can call
>>>>> something like
>>>>> includeRessourceScriptLibrary(facesContext,"jspopup/JSPopup.js")
>>>>> (similar helper for css, ...), and the code calling the above
>>>>> servlet is automatically included in the page.
>>>>>
>>>>> Any thoughts on this ?
>>>>>
>>>>> Sylvain.
>>>>>
>>>>>
>>>>>
>>>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>>>>
>>>>> This email with attachments is solely for the use of the individual or
>>>>> entity to whom it is addressed. Please also be aware that the DnB NOR Group
>>>>> cannot accept any payment orders or other legally binding correspondence
>>>>> with
>>>>> customers as a part of an email.
>>>>>
>>>>> This email message has been virus checked by the virus programs used
>>>>> in the DnB NOR Group.
>>>>>
>>>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>>
>
Re: SV: Javascript Hell
Posted by Sylvain Vieujot <sv...@apache.org>.
I'll try to do the Servlet to handle the script case at least, and I'll
apply it to the popup component, which is one of the simplest case.
I think we will find a nice solution for CSS along the road.
Breaking HTML 4 conformance isn't fine, but I don't like either the
solution to add a mandatory tag in the head.
Indeed, sometime, it's convenient to use jsf only to a section of a
page, and let jsp handle the rest (including the head).
Also, it requires yet another step to use the component, and I really
would like to avoid that.
Sylvain.
On Wed, 2004-12-01 at 10:04 +0100, Manfred Geiler wrote:
> Sylvain Vieujot wrote:
> > On Tue, 2004-11-30 at 17:16 +0100, Manfred Geiler wrote:
> >
> >>Sylvain,
> >>I understand your concerns and I agree that there is already some kind
> >>of javascript hell that will become worse.
> >>But there are some important issues to consider first:
> >>1. There are two kinds of resources
> >> a. those a component needs for rendering directly (e.g. images)
> >> b. those, that must be referenced in HTML Head (javascript, css)
> >>2. Handling resources via Servlet can be implemented fast in a simple
> >>way, i.e. getting the Stream for the given name and stream it to the
> >>client. But keep in mind that this is not the only thing a
> >>sophisticated, performance optimized ResourceServlet must do: think of
> >>caching, handling browser HTTP HEAD requests instead of GET, etc.
> >>So we should take a look at Tomcats DefaultServlet first, before
> >>reinventing the wheel.
> >>
> >
> > You're right, but anyway, I think this is not the difficult part.
> >
> >>3. The facility method is easy to implement for (1.a.) but difficult to
> >>handle for (1.b.). There are two possible solutions:
> >> a. To automatically render the link or script tags in the html head
> >>only if they are really needed, the whole page rendering must be
> >>buffered (difficult, particularly when jsp includes or tiles are used).
> >>Inspecting the component tree prior to rendering is no solution because
> >>on first page access the component tree is empty!
> >> b. The user must configure, which components he is using either
> >>globally in web.xml or as attributes to the tag that Hermod mentions.
> >>
> >
> > for 1.b, I agree that they might not be any easy way to render the link
> > in the head. But I tried to include script links and css links in the
> > body, and it works fine.
> > Is there any objection to do this ? It would really make the all thing easy.
> > For the <script src="..."></script>, it's definitely allowed to use it
> > in the body :
> > http://www.w3.org/TR/html401/interact/scripts.html
>
> Yes, only thing to take care of is to not reference a script twice. This
> could either be handled by the components themselves or by the facility
> method you mentioned.
>
>
> > For the <link ...> element the specs says that it should go only in the
> > head ... BUT the limited tests I did show that it works (I don't know if
> > it always works though).
> > http://www.w3.org/TR/html401/struct/links.html#h-12.3
> > My guess is that it works, but it fails to provide the user with the
> > style sheet alternatives. I don't think this is a problem though as the
> > style sheets we will include this way are meant for the components, not
> > for the whole page display.
> >
> > What do you think ?
> > Can we still do it for style sheets ?
> > Is there another way to do it for <link ...> elements or for style sheets ?
>
> Hmmm. This means we would knowingly break HTML 4.01 conformance. I fear,
> people will rail against this if they validate the HTML code that is
> rendered by MyFaces.
> I suggest the following: We always include a css link for every
> component on every page. This would be the standard configuration and
> since browsers cache css I don't think this would be a performance
> problem. To allow MyFaces to automatically include something in the html
> head we introduce a new extended tag that the user must include in the
> head sections of his JSP. This is the tag that Hermod mentioned.
> We could then add expert configuration params that allow to explicitly
> disable single components, so that there is no unnecessary link rendered.
> Another way is, to not use <link> or <style> at all and only use inline
> style attributes. This is what the HtmlTabbedPaneRenderer does. Drawback
> is that it is then impossible to alter css for a component without
> subclassing the renderer.
>
> WDYT?
>
>
> > I don't like the solution of asking the user to configure which
> > components he is using, as it's quiet inefficient, error prone, and add
> > yet another level of complexity.
>
> Yes, agreed, using components should be as easy as possible.
>
>
> Manfred
>
>
>
>
> >>
> >>hermod.opstvedt@dnbnor.no <ma...@dnbnor.no> wrote:
> >>> Hi
> >>>
> >>> Another solution is to add another tag to the lib, which the developer
> >>> could add at the top of the page - ala the Struts <html:script> tag.
> >>> Making it parameterless so that it could itself find out which librarys
> >>> to load
> >>> or
> >>> add some more fuctionality to the view <f:tag> so that it would render
> >>> the <link> stuff.
> >>>
> >>> Hermod
> >>>
> >>> -----Opprinnelig melding-----
> >>> *Fra:* Sylvain Vieujot [mailto:svieujot@apache.org <ma...@apache.org>]
> >>> *Sendt:* 30. november 2004 13:47
> >>> *Til:* MyFaces Development
> >>> *Emne:* Javascript Hell
> >>>
> >>> Hello everybody,
> >>>
> >>> Right now, some components require you to include some javascript
> >>> libraries in your app, and to reference those libraries in your
> >>> page's header.
> >>> Just for your example webapp, the header looks like that :
> >>>
> >>> <!-- JSCook Menu -->
> >>>
> >>> <script language="JavaScript" src="jscookmenu/JSCookMenu.js" type="text/javascript"></script>
> >>> <script language="JavaScript" src="jscookmenu/ThemeOffice/theme.js"></script>
> >>> <link rel="stylesheet" href="jscookmenu/ThemeOffice/theme.css" type="text/css">
> >>> <script language="JavaScript" src="jscookmenu/ThemeMiniBlack/theme.js"></script>
> >>> <link rel="stylesheet" href="jscookmenu/ThemeMiniBlack/theme.css" type="text/css">
> >>> <script language="JavaScript" src="jscookmenu/ThemeIE/theme.js"></script>
> >>> <link rel="stylesheet" href="jscookmenu/ThemeIE/theme.css" type="text/css">
> >>> <script language="JavaScript" src="jscookmenu/ThemePanel/theme.js"></script>
> >>> <link rel="stylesheet" href="jscookmenu/ThemePanel/theme.css" type="text/css">
> >>>
> >>> <!-- JSCalendar -->
> >>> <script language="JavaScript" src="jscalendar/popcalendar.js" type="text/javascript"></script>
> >>> <link rel="stylesheet" href="jscalendar/jscalendar-WH/theme.css" type="text/css">
> >>> <link rel="stylesheet" href="jscalendar/jscalendar-DB/theme.css" type="text/css">
> >>>
> >>> <!-- JSPopup -->
> >>> <script language="JavaScript" src="jspopup/JSPopup.js" type="text/javascript"></script>
> >>>
> >>>
> >>> I'm now working on a new component that is javascript intensive too,
> >>> and that would require the include of at least 5 other .js files.
> >>>
> >>> I think we should make this transparent to the user by :
> >>>
> >>> * Including the scripts/css/whatever required in the myfaces.jar
> >>> file as resources. So, we are sure we always have the .js
> >>> file's version that works, and the developer just needs to
> >>> include the myfaces lib. (this will grow a bite the size of
> >>> the jar though).
> >>> * Have the components load the script/css/whatever in a standard
> >>> way so that the page's developer doesn't need to bother, and
> >>> so that the script/css/... is only included once in the page.
> >>>
> >>> So, starting to think about a solution for this, here is my first idea :
> >>>
> >>> - Have all those scripts/css/... as resources
> >>>
> >>> - Make an additional servlet that the webapp developper would
> >>> include in his web.xml declarations, and that would be invoqued like :
> >>> http://my.webserver.com/webapp/myFacesRessource?name=jspopup.js
> >>>
> >>> This is the only thing the webapp developper would have to do
> >>> (declare the servlet), but I don't see how we could avoid that
> >>> without writing the scripts/css/... into the page.
> >>> Writing the scripts/css/... into the page would be bad for
> >>> caching, and wouldn't allow us to use standard images with this
> >>> facility.
> >>>
> >>> - Have a facility so that the component's renderer can call
> >>> something like
> >>> includeRessourceScriptLibrary(facesContext,"jspopup/JSPopup.js")
> >>> (similar helper for css, ...), and the code calling the above
> >>> servlet is automatically included in the page.
> >>>
> >>> Any thoughts on this ?
> >>>
> >>> Sylvain.
> >>>
> >>>
> >>>
> >>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >>>
> >>> This email with attachments is solely for the use of the individual or
> >>> entity to whom it is addressed. Please also be aware that the DnB NOR Group
> >>> cannot accept any payment orders or other legally binding correspondence
> >>> with
> >>> customers as a part of an email.
> >>>
> >>> This email message has been virus checked by the virus programs used
> >>> in the DnB NOR Group.
> >>>
> >>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *