I am wondering if this may not be a great idea as it may break people since CoreRenderer is API and not IMPL. Any ideas on how I can do this in a way to ensure that the client behaviors are decoded but not break the API?
-Andrew On Wed, Feb 10, 2010 at 10:39 AM, Andrew Robinson <[email protected]> wrote: > I need to add the ClientBehavior decoding logic to Trinidad as I > forgot to do it earlier > (https://issues.apache.org/jira/browse/TRINIDAD-1715). I would like to > put the logic in the renderer, not in UIXComponentBase as it makes > much more sense to have it there. I need to make sure the method is > called so that people don't subclass the method and forget to call the > parent method. I would like to make the following additions to > CoreRenderer: > > �...@override > public final void decode( > FacesContext facesContext, > UIComponent component) > { > FacesBean facesBean = getFacesBean(component); > String clientId = null; > if (facesBean != null) > { > clientId = decodeBehaviors(facesContext, component, facesBean); > } > decode(facesContext, component, facesBean, clientId); > } > > /** > * Hook for sub-classes to perform their own decode logic > * @param facesContext the faces context > * @param component the component to decode > * @param facesBean the faces bean for the component > * @param clientId the client ID if it has been retrieved already > * during decoding, otherwise it will be null. Passed in for performance > * reasons, so that if it has already been retrieved it will not need to be > * retrieved again > */ > protected void decode( > FacesContext facesContext, > UIComponent component, > FacesBean facesBean, > String clientId) > { > // No-op > } > > Even though this seems the right thing to do, I know that any > renderers that sub-class CoreRenderer or XhtmlRenderer will need to be > updated. I will obviously convert the Trinidad renderers. Do you all > concur that this is the right thing to do, an also if you are okay > with the API of the new contract? > > Thank you, > Andrew >
