I created two tickets: Renderer modification => https://issues.apache.org/jira/browse/TRINIDAD-1610 Event part (setParent() behavior) => https://issues.apache.org/jira/browse/TRINIDAD-1611
-Matthias On Mon, Oct 26, 2009 at 3:51 PM, Matthias Wessendorf <[email protected]> wrote: > oh, yeah... of course this can only work when we change our > UIXComponentBase's setParent() to trigger the new "PostAddToViewEvent" > event. > > A simple implementation of the setParent() is available here: > http://svn.apache.org/repos/asf/myfaces/core/trunk/api/src/main/java/javax/faces/component/UIComponentBase.java > (No, due to licensing issues, I am not looking at the RI code...) > > As this event subsystem doesn't come for free (in terms of PERF > costs), I will try to get some numbers on the inclusion of the > behavior. > However, the benefit of the "relocatable resources" feature is that we > don't need to worry about "duplicated" resources, as something like > this: > ... > <h:outputScript target="body" name="fooBody.js"/> > <h:outputScript target="body" name="fooBody.js"/> > <h:outputScript target="body" name="fooBody.js"/> > ... > > Is only added once to the particular *target*... > > Greetings, > Matthias > > On Mon, Oct 26, 2009 at 3:45 PM, Matthias Wessendorf <[email protected]> > wrote: >> Hi, >> >> in order to avoid dependency to h:head/body/form BUT be able to >> support the "Relocatable Resources" feature, we should change our >> renderers for "head", "body" and "form" to check >> for any component resource(s) that has been targeted to one of these guys. >> >> This would mean that something like this just works: >> <tr:document >> xmlns="http://www.w3.org/1999/xhtml"; >> xmlns:f="http://java.sun.com/jsf/core"; >> xmlns:h="http://java.sun.com/jsf/html"; >> xmlns:tr="http://myfaces.apache.org/trinidad"; >> title="TESTER of Scripts"> >> >> <h:outputScript target="body" name="myCoolBody.js"/> >> <h:outputScript target="head" name="anAwesomeHead.js"/> >> >> </tr:document> >> ==> no need to add the nasty h:head/body. >> >> The call inside of the renderer should be fairly simple: >> ... >> for(UIComponent comp : >> context.getViewRoot().getComponentResources(context, "head")) >> { >> comp.encodeAll(context); >> } >> ... >> Note: We need to render out these resources pretty much BEFORE we end >> the particular HTML element (e.g. "head", "body" or "form")... >> >> In order to avoid duplicated code, I think we want to add a utility >> which should be called from particular renderers, like on >> CoreRenderer.java (part of the Trinidad API). This would allow >> extensions to easily use this new API as well... >> >> suggested change to CoreRenderer.java => >> /** >> * Hook for rendering the component resources for the <code>target</code>. >> * @param context Current <code>FacesContext</code> object for this request. >> * @param target The target for the resources (e.g. head/body/form) >> * >> * @throws IOException >> */ >> protected final void encodeComponentResources( >> FacesContext context, >> String target) throws IOException >> { >> if(target != null) >> { >> UIViewRoot viewRoot = context.getViewRoot(); >> for(UIComponent componentResource : >> viewRoot.getComponentResources(context, target)) >> { >> componentResource.encodeAll(context); >> } >> } >> } >> >> As a matter of fact the HeadRenderer's encodeEnd() method would simply >> look like: >> >> protected void encodeEnd( >> FacesContext context, >> RenderingContext arc, >> UIComponent comp, >> FacesBean bean) throws IOException >> { >> ResponseWriter rw = context.getResponseWriter(); >> >> // trigger the rendering of targeted resource >> // for the HEAD, on UIViewRoot - if there are >> // any... >> encodeComponentResources(context, "head"); >> >> rw.endElement("head"); >> } >> >> -Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
