Ah, but remember that the OP didn't want to reimplement every renderer -
and that process has gotten considerably harder in the new spec as well,
with the implementation of the Behavior interface and it's ajax
ramifications. I'd hardly recommend it as a matter of course any more -
it's just gotten way harder.
I wonder - would it really break that many programs to change the spec
to remove tables and replace them with some smart (and unspecified in
behavior, though specified in name) css?
Jim
On 7/13/09 8:48 AM, Ed Burns wrote:
>>>>>> On Sat, 11 Jul 2009 02:25:56 -0700, Jim Driscoll<Jim.Driscoll_at_Sun.COM> said:
>
> JD> On 7/11/09 12:15 AM, webtier_at_javadesktop.org wrote:
>
> SL> I am often working with frontend developers saying, they would not
> SL> like to introduce JSF into a project because of rendering of
> SL> components. Indeed some of the more complex components have
> SL> renderers that produce very "oldschool" or deprecated html (nested
> SL> tables is a common example). Well, if you can abandon the usage of
> SL> these components... no problem at all.
>
> JD> Sadly, the spec is pretty clear about how those tags should be rendered,
> JD> so there's little we can do without badly breaking existing code. But
> JD> yeah, I feel the same twinge of annoyance every time I see that.
>
> Don't forget, you can easily override any of the renderers in the
> standard-html renderkit and your one will automatically be used instead
> of the one supplied by the JSF implementation.
>
> For example, if you don't like how we violate WCAG guidlines in our
> implementation of the javax.faces.Panel javax.faces.Grid renderer [1],
> it is trivial to override it and do your own thing. All existing JSF
> books, including mine, and also the J2EE tutorial cover how to do this.
>
> You can override as many or as few renderers in this way. This feature
> is a core part of JSF and has been present since 1.0.
>
> [1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/renderkitdocs/index.html
>