On 7/12/09 12:17 PM, webtier_at_javadesktop.org wrote:
> That was a quick reply. Yeah, separation of html and event handling/binding... that was the term I had in mind.
>
> Our designers astonish me again and again, what's possible with html/css/javascript. These guys and girls have long year experience dealing with even older browsers like the IE 5.5. As far as I know these older browser have more problems with css than with javascript. Their general approach is to seperate all javascript completely from html in different files. Because in JSF the javascript is partly generated per request by script renders, this division in seperated files leads to seperate requests and is hardly to archive. Using an inline block for generated javascript would also be sufficient solution for me.
I'm still not clear on what really is accomplished by it - it seems more
of a stylistic requirement than a technical one. Would that be a fair
statement?
> I digged a little into the rendering process... also into RenderKitUtils. Quite a mass of static methods around there.
Yep, it's evolved over the course of 5 years, and it's probably past
time for a refactor. But most of the functionality is pretty localized.
The two methods I directed you to (the renderOnchange and
renderOnclick methods), along with the methods they call, hold all the
code that renders the attributes that you care about.
> I had the hope one can change the rendering of some attributes without touching all the other render classes, even it's not portable to other implementations. Is there a chance the rendering of attributes will become hookable in any way even it is not in the specs?
By changing those two methods, you get just that. Granted, it's not the
easiest code to trace, since it got all larded up with more
spec-required flexibility in the last rev, but that's about as good as
it can get for the time being. It's not clear that your requirement is
a general enough one to merit the work to make the event attribute
generation swappable - especially since we've already done all this work
with the swappable behavior interface. And if you're not worried about
portable code, or adding behaviors other than the ajax behavior that's
encapsulated in the f:ajax tag.
If other people think that this is the sort of thing you'd like us to
support, please let us know by chiming in.
Jim