I like very much Andrew's idea of having more smaller renderers
and being able to override them the standard way (via faces-config.xml)

Also maybe some of you understood me wrong.
I didn't mean that all/most of the renderer methods should be protected.

But there are cases where it's needed.
Lets take for example some not so trivial scripts that are generated
in a private method,
which is called from a larger protected method.
If somebody wants to override the protected method,
it has to duplicate the script rendering method because he can't call it.

IMO it's not so hard to think of a stable method signature for that
kind of cases.


On 4/11/08, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Sounds like a reasonable suggestion - I would love to be able to
> replace/extend small chunks of code, not having to rewrite/copy the
> renderer-code fully, so this suggestion might go into this direction.
>
> regards,
>
> Martin
>
> On 4/11/08, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > Okay, I have yet another approach that I thought of while walking my
> > dogs that is much more JSF-ish and goes along with Christi's email on
> > sub-renderers.
> >
> > Instead creating a whole bloody wrapper API framework that would make
> > the API hard to change, what about breaking the renderers down even
> > more into subclasses.
> >
> > Take the tr:panelPopup for example again. It has:
> > Outer container
> > Trigger
> > Popup
> >   Title bar
> >   Close button
> >   Body
> >
> > So lets say this is how the renderer could be built:
> > First, create a bunch of renderer types:
> > org.apache.myfaces.trinidad.Popup
> > org.apache.myfaces.trinidad.Popup.Trigger
> > org.apache.myfaces.trinidad.Popup.PopupShell
> > org.apache.myfaces.trinidad.Popup.TitleBar
> > org.apache.myfaces.trinidad.Popup.ButtonArea
> > org.apache.myfaces.trinidad.Popup.Body
> >
> > Then register a default renderer for each of these types.
> >
> > Then the PanelPopupRenderer would in encodeAll:
> >
> > render outer DIV (ppr stuff)
> > call a render utils method to get the renderer for the trigger and encode
> it
> > call a render utils method to get the renderer for the popup shell and
> > encode it
> >
> > in the popup shell renderer:
> > encode the outer HTML
> > call a render utils method to get the renderer for the title bar and
> encode
> > it
> > call a render utils method to get the renderer for the popup body and
> encode
> > it
> >
> > in the title bar renderer:
> > encode the outer HTML
> > encode the title
> > call a render utils method to get the renderer for the button area and
> > encode it
> >
> > in the body renderer:
> > encode the outer HTML
> > encode the children components
> >
> > This way there are many renderers to one component. The renderers
> > would be registered in the faces-config.xml just like any ordinary
> > renderers. Since the FacesBean allows renderers to encode any
> > component that has certain property keys, this is ideal.
> >
> > Take for example the close button on the popup, we could have a faces
> > bean alias wrapper. What I mean by this is something like this:
> >
> > public class PopupTitleBarRenderer extends XhtmlRenderer {
> >   protected void encodeAll(FacesContext context, RenderingContext rc,
> >     UIComponent component, FacesBean bean) throws IOException {
> >     FacesBean wrapped = new AliasedFacesBean(bean);
> >     wrapped.map("text", "title");
> > ...
> >
> > This way a command button renderer could be used to render the close
> > button using the title from the dialog as the text of the button.
> >
> > Using this way, the only exposed API are the sub-renderer types that
> > can be defined in the faces config. New types can be added and old
> > ones removed without breaking Java interfaces or abstract class APIs
> > (although it would have to be controlled to not break custom code too
> > badly).
> >
> > -Andrew
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>


-- 
Cristi Toth

-------------
Codebeat
www.codebeat.ro

Reply via email to