First, please read: http://www.nabble.com/How-to-reply-to-emails-tf3182877.html#a8833555
With separate create/render phases, finding all components that *might* output data into the head is not difficult; they could simply register themselves on create, or a tree-walk could be done as you describe.
The problem is that at the time the head component is rendered it is not obvious which of the components that *might* output data into the head are actually rendered.
The rendered state of a component depends upon the rendered state of all its parent components, so the rendered property of many components in the page would need to be evaluated. And in some cases evaluating a rendered EL expression can have side-effects; yes it is poor style to do so but it's not uncommon.
Cheers, Simon noah wrote:
Why couldn't all the components that need resources implement some interface and then have the h:head component walk the component tree looking for components implementing the interface? On 3/22/07, Simon Kitching <[EMAIL PROTECTED]> wrote:Mike Kienenberger wrote: > Roger blogged, >> With separate build and render phases, you could have a <h:head> >> component which >> other components could add resources to as they are created during the >> tree build. > > Hmm. I wonder if we could implement this for facelets/branch 1.2. Probably not. The point is that components don't know at the time they are *created* whether they want to insert stuff into the head or not; they only know that at *render* time. And by then the head tag has already rendered itself. Well, unless we allow every component in the page to output its required resources regardless of whether it is later rendered or not. A head tag could be useful though; currently the ReducedHTMLParser is needed to parse the page and find the <head> tag. It's not simply a matter of looking for that string due to things like <!-- the <head> is not here --> <script> var s = "<head>"; </script> etc. However a head tag could output a unique marker like <!--HEAD12345567890--> which could more easily be scanned for by the ExtensionsFilter. This marker approach is already used for figuring out where to insert serialized client state etc. Items 1,2 and 3 of the blog are all issues that could be pretty easily fixed in the ExtensionsFilter. Not that I'm claiming it's a great solution, but a fixed ExtensionsFilter would be better than hand-coding resources in the head section. Cheers, Simon
