Skip to main content

Rendering of javascript on[click|change|*] event handlers

7 replies [Last post]
tzwoenn
Offline
Joined: 2005-07-01

I am often working with frontend developers saying, they would not like to introduce JSF into a project because of rendering of components. Indeed some of the more complex components have renderers that produce very "oldschool" or deprecated html (nested tables is a common example). Well, if you can abandon the usage of these components... no problem at all.

But there is one point with the introduction of partial page rendering also affecting all the default components. Most of the frontend developers agree on the design principle that event handlers as part of the solution for asynchronous request should not be rendered directly on the tags itself's, but rather in an inline javascript part in the html or a separate javavscript file, that binds the event handlers to the tag element.

To cut a long story short: Is it possible to modificate the rendering of some tag attributes without rewriting a complete renderer for all components? I would like to relocate the output of the ScriptRenderer into a single location and bind the event handlers either using hand written wiring code or using a common javascript framework like YUI or JQuery.

Thanks in advance,

Sven Linstaedt

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Ed Burns

>>>>> On Sat, 11 Jul 2009 02:25:56 -0700, Jim Driscoll said:

JD> On 7/11/09 12:15 AM, webtier@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....

--
| ed.burns@sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Jim Driscoll

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 said:
>
> JD> On 7/11/09 12:15 AM, webtier@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....
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Ed Burns

>>>>> On Mon, 13 Jul 2009 09:06:55 -0700, Jim Driscoll said:

JD> Ah, but remember that the OP didn't want to reimplement every renderer -
JD> and that process has gotten considerably harder in the new spec as well,
JD> with the implementation of the Behavior interface and it's ajax
JD> ramifications. I'd hardly recommend it as a matter of course any more -
JD> it's just gotten way harder.

I still don't see why they'd have to re-implement any more than just the
ones they want to affect. Your point about Behaviors is a good one,
though. You may be able to do something where the existing behavior can
somehow be decorated.

JD> I wonder - would it really break that many programs to change the spec
JD> to remove tables and replace them with some smart (and unspecified in
JD> behavior, though specified in name) css?

No, there is no worry about breakage. It's just time.

Ed
--
| ed.burns@sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Jim Driscoll

On 7/11/09 12:15 AM, webtier@javadesktop.org wrote:
> I am often working with frontend developers saying, they would not like to introduce JSF into a project because of rendering of components. Indeed some of the more complex components have renderers that produce very "oldschool" or deprecated html (nested tables is a common example). Well, if you can abandon the usage of these components... no problem at all.

Sadly, the spec is pretty clear about how those tags should be rendered,
so there's little we can do without badly breaking existing code. But
yeah, I feel the same twinge of annoyance every time I see that.

> But there is one point with the introduction of partial page rendering also affecting all the default components. Most of the frontend developers agree on the design principle that event handlers as part of the solution for asynchronous request should not be rendered directly on the tags itself's, but rather in an inline javascript part in the html or a separate javavscript file, that binds the event handlers to the tag element.

So, you want to inject event listeners into the page, separated from the
tags whose events they'll intercept? Um, ok. That seems to be taking
separation of concerns too far, IMO, but ok - if that's what your
designer insist upon, then I guess you've got little choice. Let me
know if that's not what you're advocating. BTW - that doesn't work too
portably in different browsers, does it? IE's totally different than
anyone else, even more than usual.

> To cut a long story short: Is it possible to modificate the rendering of some tag attributes without rewriting a complete renderer for all components? I would like to relocate the output of the ScriptRenderer into a single location and bind the event handlers either using hand written wiring code or using a common javascript framework like YUI or JQuery.

Sure, if you're able to modify the source code to Mojarra, it's easy.
Otherwise, not so easy, without modifying all of the rendering
components (which is about 10 or so, it's not an impossible task). In
Mojarra, just find RenderKitUtils, and find the renderOnchange and
renderOnclick methods... It should be a relatively simple thing to
cache the information instead of outputting it right then, then flushing
it to the page when closing the document. Tracing the codepath from
something like renderOnchange is pretty hard, but if you're assuming no
additional added behaviors, you should be able to shortcircuit out of
that without too much pain - most of the extra stuff in there is to
allow for new added behaviors.

Jim

Jim Driscoll

> Thanks in advance,
>
> Sven Linstaedt
> [Message sent by forum member 'tzwoenn' (tzwoenn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=355217
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

tzwoenn
Offline
Joined: 2005-07-01

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 digged a little into the rendering process... also into RenderKitUtils. Quite a mass of static methods around there. 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?

BR, Sven

Jim Driscoll

On 7/12/09 12:17 PM, webtier@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

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

tzwoenn
Offline
Joined: 2005-07-01

> 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?

It's obviously not really a technical issue. Event binding on Tags can only lead to javascript errors, if you refer to other elements and the DOM is not ready after all. That could only be the case, if you click *very* fast. No, it rather a psychological issue, which affects the willingness to adopt JSF. If frontend developers / designers are not happy with the resulting html JSF produce and they are not able to "customize" it their way, the chance refusal rises. IMHO one can use JSF for all kind of website types, even pixel, if you have some sticking points in mind. But many people out here think it is rather for backoffice systems due to it's lack customizable html generation.