myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manfred Geiler <>
Subject Re: SV: Javascript Hell
Date Wed, 01 Dec 2004 09:04:04 GMT
Sylvain Vieujot wrote:
> On Tue, 2004-11-30 at 17:16 +0100, Manfred Geiler wrote:
>>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 :

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).
> 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.


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


>> <> 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 [ <>]
>>>     *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 :
>>>         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.
>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

View raw message