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="" it's definitely allowed to use it in the body :
http://www.w3.org/TR/html401/interact/scripts.html
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
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 ?
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.
If we can indeed include
I hope I did not sound too pessimistic, I only wanted to address some important points from my POV before we "jump into the water". ;-) Manfred [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] > *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="" type="text/_javascript_"></script> > <script language="_javascript_" src=""> > <link rel="stylesheet" href="" type="text/css"> > <script language="_javascript_" src=""> > <link rel="stylesheet" href="" type="text/css"> > <script language="_javascript_" src=""> > <link rel="stylesheet" href="" type="text/css"> > <script language="_javascript_" src=""> > <link rel="stylesheet" href="" type="text/css"> > > <!-- JSCalendar --> > <script language="_javascript_" src="" type="text/_javascript_"></script> > <link rel="stylesheet" href="" type="text/css"> > <link rel="stylesheet" href="" type="text/css"> > > <!-- JSPopup --> > <script language="_javascript_" src="" 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. > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
|
|
