JSR 314 says:
First class support for bundling and delivering static resources
associated with a component: images, stylesheets, scripts, etc. Should
be able to specify default locations for resources.
Two options:
-start impl and move to faces² asap
-wait
On 10/26/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> 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 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.
> 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.
>
> What do you think, is it all worth it?
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
