myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <svieu...@apache.org>
Subject Re: SV: Javascript Hell
Date Wed, 01 Dec 2004 13:33:17 GMT
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 <mailto:hermod.opstvedt@dnbnor.no> <mailto:hermod.opstvedt@dnbnor.no
<mailto:hermod.opstvedt@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 <mailto:svieujot@apache.org>
<mailto:svieujot@apache.org <mailto:svieujot@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.
> >>>>> 
> >>>>> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * *
> >>
> > 

Mime
View raw message