This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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:
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?
True wisdom is in knowing you know nothing - Socrates
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.
Customer surveys are for companies who didn't pay proper attention to begin with.
Well, I am using ajax in the element. Here is the jsf for it:
and here is the onclick from the generated html:
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)
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.
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.
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.
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.
"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.
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 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.
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.