See below > > 3) introduce some configurable way to override default behavior for > > rendering certain areas of components. > > > > > That would be fine, as long as there's not a perf issue, and there's an > understanding that things may break at the next release - hopefully rare, > but possible.
Gab, I completely understand your concerns for performance issues, so I created a really simple component that renders a header, body and footer (3 DIVs in an outer DIV). In my tests, I had one facet for the header and one attribute for the footer, to try to capture a small portion of a real world situation. I created 3 renderers. Each rendered the content exactly the same: <div id="comp"> <div>header</div> <div>body</div> <div>footer</div> </div> Renderer 1: No sub-renderers and no delegating renderers either. It simple does all the encoding in the encodeAll method. Renderer 2: Looks up sub-renderers one time (in the findTypeConstants method) for the header and footer areas. The main renderer renders the outer div and the body div and delegates the rendering of the header and footer to the sub-renderers. Renderer 3: Looks up sub-renderers during the encodeAll for the header and footer areas. The main renderer renders the outer div and the body div and delegates the rendering of the header and footer to the sub-renderers. I don't think the third renderer style would be necessary, as it would be very rare to want to change a sub-renderer to a new class without changing the main renderer (the only time it would make a difference). I used the CoreRenderKitPerf.java JUnit code to run the test. I just ran the test from inside Eclipse. Each test had the renderer render itself 25,000 times and over 12 loops, threw out the best and the worst and took the average of the 10 remaining. I shifted which was run first to not give any preference to one test. Here are the results for the average time for each encode (25,000 times) (average of the 10 runs): Renderer 1: 145.8 ms Renderer 2: 138.5 ms Renderer 3: 149.4 ms Here is the time for one encodeAll invocation: Renderer 1: 0.00583 ms Renderer 2: 0.00554 ms Renderer 3: 0.00598 ms So as you can see, there is no measurable difference between the 3 with statistical error. The renderer 3 is slightly slower. The fact that renderer 2 is faster is probably a test anomaly, but you can see that it really doesn't make any difference. The only overhead is 2 more method invocations (calling delegateRenderer and encodeAll in that method). So method 2 (look up the sub-renderers in findTypeConstants) is just as fast and method 3, if deemed desirable is a small hit. I would recommend method 2, as I doubt method 3 would be desired. If you want to see the code, do a log with stop on copy on: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/ar_subRendererPerfTesting -Andrew
