> > The Renderer has to implement that interface then. > Implementing interface would break TCK test of JSF spec.
custom renderer. those aren't "bound" to TCK -M > > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
