Skip to main content

JSF 2.0: Errors or Ambiguity in Spec for "onevent" JavaScript Callback

8 replies [Last post]
martyhall
Offline
Joined: 2009-08-19

IMHO, section 14.4.1 of JSF_20090506.pdf is unclear.

1) Table 14-4 refers to responseTxt, but in my Mojarra build (Mojarra 2.0.0 SNAPSHOT 20090924), it is responseText. Since responseText is the property in the standard XMLHttpRequest, I presume that was what was intended, and Table 14-4 is in error.

2) It is not clear to me from reading the spec that it is the "status" property that should be "begin", "success", or "complete". Those three conditions are described clearly, but to me it is far from obvious from the spec that it is the status property that should contain this information. I confirmed it with Firebug, but I don't see it in the spec. I would think "status" should be one of the entries in the left column of Table 14-4. For example:

function oneventhandler(data) {
if (data.status == "begin") {
showSomeAnimatedGifSayingImWorking();
} else if (data.status == "success") {
hideSomeAnimatedGifSayingImWorking();
}
}

3) Table 14-4 says that there should be a name property that refers to the callback handler's name, but it was not present in my implementation. It is not exactly obvious to me why this property would be useful, but nevertheless, Table 14-4 says it should be there, and it isn't.

4) I would reorder Table 14-3 so that the entries are in chronological order (begin, complete, success).

Cheers-

- Marty
http://www.coreservlets.com

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
martyhall
Offline
Joined: 2009-08-19

PS The use case of 14.4.1.1 is incorrect.

First, you can't call addOnEvent(statusUpdate) until [b]after[/b] the statusUpdate variable exists. Even it it existed at that point, redefining it later as shown would have no effect because addOnEvent would have the old value.

Second, there is no point in doing var statusUpdate = function statusUpdate.... In JavaScript, doing function foo(...) {...} is the same as doing var foo = function(...) { ... }. So, just do function statusUpdate....

I suggest changing the use case of 14.4.1.1 to this:

function statusUpdate(data) {
// do something with data.status or other parts of data payload
}
...
jsf.ajax.addOnEvent(statusUpdate);

I also think that this part of the spec should make it a bit more obvious to readers that
invokes addOnEvent.

Cheers-

- Marty
http://www.coreservlets.com

driscoll
Offline
Joined: 2003-06-06

Marty -

While the spec leads do monitor these forums, the best way to report specification bugs is to log them as bugs in the specification bug database:

https://javaserverfaces-spec-public.dev.java.net/servlets/ProjectIssues

Or, optionally, you can email the spec comments alias:

jsr-314-comments@jcp.org

One comment on your comment though:

var foo = function foo()

is not quite the same as

var foo = function()

One will show up as function foo in debug stats. The other will not. It's good practice to always name your functions, even when assigning them to variables, for exactly this reason.

martyhall
Offline
Joined: 2009-08-19

> While the spec leads do monitor these forums, the
> best way to report specification bugs is to log them
> as bugs in the specification bug database:

Roger; wilco. Will do.

> One comment on your comment though:
>
> var foo = function foo()
>
> is not quite the same as
>
> var foo = function()
>
> One will show up as function foo in debug stats. The
> other will not. It's good practice to always name
> your functions, even when assigning them to
> variables, for exactly this reason.

I don't understand why you don't do function foo(...) { ... } instead of [b]either[/b] of those two forms. Isn't that the same as the first form above? Can you elaborate, please?

Cheers-

- Marty
http://www.coreservlets.com

driscoll
Offline
Joined: 2003-06-06

We had to adopt best practices as part of our development process - the best practices that I've chosen to follow come from Crockford's excellent "JavaScript: The Good Parts".

This is one of those best practice recommendations - it aids code readability, since it disambiguates function statements and function expressions.

I really can't say enough about Crockford's book - it's almost as good as the classic K&R.

martyhall
Offline
Joined: 2009-08-19

> We had to adopt best practices as part of our
> development process - the best practices that I've
> chosen to follow come from Crockford's excellent
> "JavaScript: The Good Parts".
>
> This is one of those best practice recommendations -
> it aids code readability, since it disambiguates
> function statements and function expressions.

Well, who am I to argue with an expert like Crockford? This is an interesting idea, and I need to read his argument for it. Still, empirically, I haven't observed that it has yet become standard practice to use
var foo = function foo(...) { ... }
instead of the shorter and equivalent
function foo(...) { ... }

I have never used YUI, which presumably uses this form. But none of jQuery, Prototype, Scriptaculous, Ext-JS, or Dojo follow this style, either in their online examples or in their source code. However, YUI is famous for better preparing for mixing with other libraries and handling other code without name conflicts, so this idea is worth looking at.

> I really can't say enough about Crockford's book -
> it's almost as good as the classic K&R.

My "best practices in JavaScript" reference has been "Pro JavaScript Techniques" by John Resig (of jQuery fame). But the Crockford book sounds like a must-read, so I just ordered it. Thanks for the tip!

Cheers-

- Marty
http://www.coreservlets.com

driscoll
Offline
Joined: 2003-06-06

Ah, but both Prototype and jQuery use a completely different coding style - they're doing Object property declarations to set things up.

Thus, they say things like this:

ImportantClass.SubClass = {

propertyName1 : function(param, param) {},
propertyName2: function(param) {}

}

Which, while perfectly valid, is painful to read when switching back and forth between Java and JavaScript. And frankly, I find it a little painful to read even when I'm not switching.

So I far prefer:

var namespace = {};
namespace.functionName = function functionName(param, param) {
};

namespace.functionName = function functionName2(param) {
};

This does the same thing (sort of - we're avoiding objects, inheritance and prototypes like the plague in our code for a variety of reasons, some of which Crockford discusses), but it's also a little easier to read for Java-trained eyes.

It's like doing a name declaration, followed by a function name and function definition.

'Sides, function functionName() is just going to pollute your global namespace anyway, and we don't want that.

We made a conscious choice to make the JSF JS code not extend any object prototypes because we want to be able to be used with any library out there, BTW. Same thing with namespacing everything.

martyhall
Offline
Joined: 2009-08-19

> [...]
> So I far prefer:
>
> var namespace = {};
> namespace.functionName = function functionName(param,param) { };
> [...]
> 'Sides, function functionName() is just going to
> pollute your global namespace anyway, and we don't
> want that.

Aha! I finally discovered my fundamental misunderstanding about all of this. I thought that
[b]foo.bar = function bar(...) {...};[/b]
was equivalent to
[b]function bar(...) {...};
foo.bar = bar;[/b]
That is, I thought that the top form created a global function called bar and then assigned it to the bar property. So, in my incorrect understanding, they [i]both [/i]would have polluted the global namespace. Shows how little I really know about JavaScript! (Of course, the same could be said for Java. :-) ) Thanks for clueing me in.

> We made a conscious choice to make the JSF JS code
> not extend any object prototypes because we want to
> be able to be used with any library out there, BTW.
> Same thing with namespacing everything.

Yes, I had noticed that, and I think this is a great thing and very well thought out. Am I correct in interpreting Section 13.2 as saying how an implementation [i]could [/i]use Open Ajax, not that implementations [i]should [/i]use Open Ajax? My look at the code suggests that Mojarra is not using Open Ajax, correct?

Thanks again for patiently explaining the var foo.bar = function bar(..) {...}; business until I [i]finally [/i]got the point.

Cheers-

- Marty
http://www.coreservlets.com

driscoll
Offline
Joined: 2003-06-06

Yep, *MAY* instead of *SHOULD*.

There was a lively discussion around that.

Our vendors don't want us including OpenAjax in the client side by default.

See the jsf-demo dir (or my blog) for discussion of doing an event bridge. It's trivial.