myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sochor Zdeněk <zdenek.soc...@ataco.cz>
Subject Re: [research] resource dependency framework
Date Fri, 26 Oct 2007 09:17:36 GMT
Hi,
  quite interesting ideas, but they have few glitches (inside).

Mario Ivankovits napsal(a):
> Hi!
>
> Sorry for the lenghty mail!! Maybe something for the upcoming MyFaces 
> Commons project.
>
> To get rid of the AddResource oddities I thought about introducing a 
> new "resource dependency framework".
> 1) DefaultAddResource is slow in performance and I don't like it to 
> buffer the output at all
> 2) StreamingAddResource is a little bit better, but requires to cache 
> the styles requested on the server which is somehow tricky
> 3) DojoAddResource (in the sandbox) is a hack too
>
> Also, solution 2 and 3 lazily request resources, which you might 
> sometimes see in rendering glitches on the client side, be it that the 
> page renders choppy due to script loading in the mid of the page, or 
> that the browser has to load the css and until then the visual 
> representation is not correct.
>
>
> The idea is (if running in an environment which allows this (JSF >= 
> 1.2, facelets) to:
> a) scan the JSF tree after it has been created and before it is going 
> to be rendered
> b) collect the required resources during creation of  the tree
Both possibilities are in wrong place - if all resources were to be 
caught, it has to scan tree after all modifications - after 
INVOKE_APPLICATION phase.
>
> both ways might require view-framework dependent hooks.
> It is a shame that even in JSF 1.2 or Facelets there is no place 
> defined in the spec where to get access to the view once built but not 
> rendered yet. Maybe someone can bring this up in JSF 2.0?
> Also b might need some investigation if this is somehow pluggable, 
> might also depend on the used framework.
>
> For this to work I'd like to introduce a new interface called 
> something like 
> org.apache.myfaces.commons.renderkit.html.HtmlResourceDependencies 
> with a method like
>
> public ResourceInfo[] getResources(UIComponent component)
>
> where ResourceInfo is something like
>
> ResourceInfo
> {
> String resource;
> ResourcePosition position; (HEADER_BEGIN, BODY_END, not sure about 
> BODY_ONLOAD)
> }
>
> The Renderer has to implement that interface then.
Implementing interface would break TCK test of JSF spec.
> With either a or b the getResources() method will be called and all 
> the required resources are collected.
> Then, with help of our t:document, t:documentHead, t:documentBody 
> (maybe we need one more) it should be possible to render the resources 
> at the correct places.
>
> Since all this happens during or after the compile-time of the view - 
> and depending how your view-framework is configured 
> (facelets.BUILD_BEFORE_RESTORE=true|false) all this might not work 
> well if the resources required depends on component value bindings. 
> But normally I think resources are static things, so it should be 
> possible to workaround that limitation.
>
> To make resource requesting work even in pure JSF 1.1 environments I'd 
> enhance our default AddResource with
> AddResource.loadResources(HtmlResourceDependencies renderer)
> with everything setup correctly this is a noop, else it delegates to 1-3.
>
Wouldn't simple splitting output of whole page to 3 (or 4) independend 
chunks do the trick (HTML example):
1st for whole head w/o finnishing </head> tag
2nd starting with </head> <body> to the inserting spot for styles (not 
sure of this splitting)
3rd for whole body w/o ending tag </body>
4th ending body + html tags

Adding resources was simple appending style's output to relevant chunk then.
After all resources included and finnishing encoding all components, 
simple combining of all chunks would make a whole page's output.

Best regards,
  Zdenek

Mime
View raw message