onclick event causing javascript error in jsf.js (jsf-impl.jar file)

[Matt Kohanek]

Hey all

I could not decide if this belongs in the js forums or here, so please move it if you believe it belongs there.

I have an onclick event on a <h:commandLink> that calls some js I created. When I bundled it as part of my ear file it worked fine. But now that custom js is part of a file on our server that we import. And ever since doing that, I get a js error, 'registerEvent not defined', and it points me to a line in jsf.js:

var f = new Function("event", arguments[i]);

jsf.js is part of jsf-impl.jar, which is a shared library on our server.

That is about as much as I know about this. Has anyone had a similar issue or any idea of a way to deal with this?

[Tim Holloway]

There's not enough information for me to tell.

jsf.js, however, is new to JSF2. It supports the JSF2 AJAX functionality. The onclick attribute, however, should not be referencing jsf.js, at least unless there's a namespace issue, since onclick mostly just pushes through your onclick javascript code verbatim.

Mostly. Don't forget that some elements return results. In that case, failure to do likewise can lead to problems. When in doubt, look at the generated HTML source for the offending control.

[Matt Kohanek]

Well, I am using ajax in the element. Here is the jsf for it:

											<h:commandLink onclick="registerDCSAction('UP_LOGIN', null);" styleClass="pnx-btn RemoveGuestError Login" action="#{uPLoginBean.login}">
												<f:ajax render=":UPErrors :CaptchaErrorPanel LoginUP :ClearGuestErrors"  execute="@this email password" />
												<span class="pnx-btn-txt">#{extra["ORDER-HISTORY-STATUS.LOGIN_TO_ACCT"]}</span>
											</h:commandLink>	

and here is the onclick from the generated html:

onclick="jsf.util.chain(this,event,'registerDCSAction(\'UP_LOGIN\', null);','mojarra.ab(this,event,\'action\',\'@this LoginUP:email LoginUP:password\',\'UPErrors CaptchaErrorPanel LoginUP ClearGuestErrors\')');return false" 

here is the rest of the generated html (I am not able to put those in the same code block, it would not display these together for some reason)

<a id="LoginUP:j_idt31"  class="pnx-btn RemoveGuestError Login" rel="nofollow">
   <span class="pnx-btn-txt">Effettua il Login</span>
</a>
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-12345:6789" autocomplete="off" />

So in the generated html I see it is calling jsf.util.chain, passing in the onclick event. This makes sense, because jsf.util.chain is where this error is triggered. I just do not understand why it cannot find the registerDCSAction function from there.

[Tim Holloway]

Hmmm. should I chide you about user-designed security systems?

And in Italian???

I'd give good odds that the reason it's failing is that you're passing in the function as a literal string to the JSF utility chainer instead of as an actual execution and the function is out of scope at the point where that string is being interpreted.

I've always found it best to keep the inline javascript to a minimum. For one thing. it's harder to debug inline. So what I'd do is just have the onclick call a simple function to do its dirty work.

As to mixing AJAX and onclick, I cannot be certain. In point of fact, I probably would have made my onclick actually be an AJAX event, but I'm looking at it from A) ignorance and B) RichFaces.

I've never gotten well-studied on the JSF2 ajax tag, since I was already hooked on a4j:support, and from what I could see the a4j version is more straightforward, despite the fact that its designers were on the committee that standardized f:ajax.

[Matt Kohanek]

Well you have given me some ideas, I will update the thread with my results.
I am curious, what indicates that I am using some user designed security? I am actually not, though I can see how some of the text I use is misleading. But none of the js there is for security, I am using my companies user api for that in the backing bean.

[Tim Holloway]

"Company" security is still user security as far as I'm concerned, and unless you have a department that works full-time on nothing but the security framework full-time, I wouldn't trust it as far as I can throw it, based on many, many years of experience. In most companies, the security framework is something handled by one or more people whose real job is something "more important". Plus user-designed security isn't integrated into the core J2EE deployment mechanisms and APIs the way that the one Sun designed is. Which means that it almost certainly depends on nobody ever, ever screwing up on their security function calls. Assuming that they knew enough to put them there to begin with. Which isn't a safe assumption once the app enters maintenance and gets dumped on junior programmers who may be outsourced from a different provider than the original coders.

How can I tell it's not the J2EE standard? Because until JEE, there was no way to force a login on a page - only by navigating to a secured page. So a page with a "login" button on it immediately rings alarm bells. Even then, hanging complex functionality off the login button is a high-risk activity. My logins are extremely spartan, because anything beyond the basic login form is a potential security exploit.

I tend to be harsh about security for a reason. I've worked a long time with webapps, and in all those years, I've never ever seen a user-designed security framework that wasn't hackable, and most of them could be hacked by unskilled personnel in under 10 minutes, no matter what "genius" invented the system. I know of one case where potentially not only could the primary webapp's database be completly exploited, but so could every other customer on that server as well - and it wasn't even an SQL injection attack. Yesterday I got a query from someone wanting to know why his daughter got "password changed" email from a bank that she doesn't even have an account with. The day before I got a blatantly obvious malware package from LinkedIn. And I'm not talking spoofs - we tracked this stuff back to registered corporate resources. Supposedly companies of this size spend more time and money on security than that.



Oh wait. They spent it all on expensive buzzword frameworks and big-name Dogbert consulting companies. Then they outsourced the work to the cheapest bidder and took the leftover cash and handed it out as executive bonuses.

But I'm not bitter. After all, it's only my financial life and reputation that they're doing this with.

[Matt Kohanek]

edit - heh, didn't know I would send you off on a rant there haha - but yeah, I have had my identity stolen twice myself, and it suuucks. I think the last time was due to Sony's negligence

So it seems the difference between my local js file and the one on the server, is that the one on the server surrounds the javascript with:

$(function() {
...
registerDCSAction();
...
});

If I add that to my local file I get the same error. From what I can find, this is apparently surrounding the javascipt functions with a namespace (in addition to being the same as document.ready). So I need to add the namespace to the js calls in the onclick events. But I do not know what the namespace default would be here, or how to declare one (I have tried a lot of educated guessing without luck). I know very little about javascript namespacing (basically what I have learned today)

So this may be better off in the js forum at this point. Unless someone here has encountered this or has an idea of how I can resolve this? I am thinking of just having them put this in its own js file on the server so there is no need to surround it with this. It is only being done now because it is being added to a bunch of other js in a file.

[Tim Holloway]

Oh yes. Any time you want to wind me up good and proper, say that quality doesn't matter. As they used to say about computers, "Never before in History has it been possible to screw up so completely so rapidly". We live in highly leveraged times, which is how 21 men managed to make a bigger change in the American way of life than an army could have 200 years ago.

One thing that it's important to remember when using jQuery with JSF: The "$" symbol has meaning to the EL processor. Which is why I recommend using the "jQuery." syntax instead.