Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Can't find JavaScript Function?  RSS feed

 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a simple example from the CoreJSF (3rd Edition) , page 123.

In my case, when I click the submit button, nothing happens. It looks like i have the project set up exactly the same way and Intellij is finding all the files when I type in things like "<h:outputScriptLibrary....>.

Here's the index.xhtml:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
xmlns:f="http://xmlns.jcp.org/jsf/core">

<h:head>
<title>#{msgs.windowTitle}</title>
<h:outputStylesheet library="css" name="styles.css"/>
<h:outputScript library="javascript" name="checkPassword.js"/>
</h:head>

<h:body>
<h:form>

<h:panelGrid columns="2" columnClasses="evenColumns, oddColumns">

#{msgs.namePrompt}
<h:inputText/>

#{msgs.passwordPrompt}
<h:inputSecret id="password"/>

#{msgs.confirmPasswordPrompt}
<h:inputSecret id="passwordConfirm"/>

</h:panelGrid>

<!--Execute JavaScript function on click of the button-->
<h:commandButton type="button" value="Submit Form" onclick="checkPassword(this.form)"/>

</h:form>
</h:body>
</html>


The checkPassword(form) JavaScript is here:



If I change the onclick on the index.xhtml to just display an alert button, then it works OK, so there's something where either the JS file isn't found, or there's something else wrong with the example code. I tried the author's code and it didn't work either.

Perhaps I have a configuration issue?

Thanks in advance,

-mike
project.png
[Thumbnail for project.png]
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your problem is that you don't understand how onclick works.

Don't make the onclick method do the submit. Make it return a boolean result value. To suppress the submit, return false, to do the submit, return true. The h:commandButton itself does the submit, based on the result.

Like so:
 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Your problem is that you don't understand how onclick works.

Don't make the onclick method do the submit. Make it return a boolean result value. To suppress the submit, return false, to do the submit, return true. The h:commandButton itself does the submit, based on the result.

Like so:


I guess you need to submit your critique to the authors of the JSF book since it was their code, nearly verbatim (except for a few comments I added), I was using.... :(

(see page 122, line 22, Core JavaServer Faces, 3rd Edition, Geary, and Hosrtmann.)

- mike
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Come to think of it, I think the proper attribute for that isn't "onclick", it's "onsubmit".
 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Come to think of it, I think the proper attribute for that isn't "onclick", it's "onsubmit".


Sorry, Tim, didn't see that one listed....see attached.

I believe I have the 4th printing of this book so I doubt "onclick" is a typo at this point.

Did you check the book to see what I'm referring to?

Thanks,

-- mike
no_onsubmit.png
[Thumbnail for no_onsubmit.png]
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I had to go back and RTFM. The onsubmit event is for h:form. And I'm not sure about onclick's ability to sense a return value now, although part of that may be some browsers acting that way.

Still, onsubmit makes more sense, since it's the totality of the form's values that are up for validation, whereas onclick requires coupling one control with 2 other controls.

Not to mention that the onsubmit method is a line or 2 less code.

 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:I had to go back and RTFM. The onsubmit event is for h:form. And I'm not sure about onclick's ability to sense a return value now, although part of that may be some browsers acting that way.

Still, onsubmit makes more sense, since it's the totality of the form's values that are up for validation, whereas onclick requires coupling one control with 2 other controls.

Not to mention that the onsubmit method is a line or 2 less code.



There must be something more basic going on here.

I changed the code as you suggested to the below, but there is still no action when I click the button.




Perhaps I misunderstood your meaning?

BTW, you can download the actual code at corejsf.com

Look forward to hearing back.

- mike
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the problems that you can get into in JSF/javascript is that the IDs of the source JSF View Template are not the same as those of the generated HTML and Javascript wants to work with the generated HTML IDs. So some care is required to get the code right.

What I do in cases like this is slap in a few more alerts to display the intermediate values and/or catch any Javascript exceptions being thrown.

Alternatively, if your browser has a Javascript debugger, step through the onclick/onsubmit function, examining the values that are being assigned and used. This works best when the Javascript is in an separate (.js) file, as it's harder to set breakpoints on JSF code.
 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:One of the problems that you can get into in JSF/javascript is that the IDs of the source JSF View Template are not the same as those of the generated HTML and Javascript wants to work with the generated HTML IDs. So some care is required to get the code right.

What I do in cases like this is slap in a few more alerts to display the intermediate values and/or catch any Javascript exceptions being thrown.

Alternatively, if your browser has a Javascript debugger, step through the onclick/onsubmit function, examining the values that are being assigned and used. This works best when the Javascript is in an separate (.js) file, as it's harder to set breakpoints on JSF code.


Hi Tim,

Yes, as shown, the .js is a separate file.

I've tried this project with two browsers. Neither works.

If I just do an "alert" on the command button, that works fine.

Nothing happens in the js file to debug. It just isn't executing.

This type of issue is one of the reasons I've stayed away from JSF...Problems that are difficult to figure out and there isn't the support like Spring.

Since this teeny, tiny project is freely available at corejsf, are you able to get it working?

Hopefully you can reproduce my issue.

- mike
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry. I've got a bad attitude. Everybody wants me to pay them, but they expect me to work for free and it tends to sour me even on places where I voluntarily work for free. Meaning that there's a limit on how much effort I put into this stuff. Usually that means I don't bother to run foreign examples or read sample code that takes up more than one screen. Nothing personal.

I've done what I described many times over the last 5-10 years - sometimes even getting paid for it. So there's nothing wrong with the basic concept.

It did occur to me that something I cannot reproduce may be causing you problems, though. If your browser is caching your Javascript file, then the reason it doesn't work is that what your browser is executing is stale code that doesn't match what's on your server.

The trick I use to force a refresh is to directly request the Javascript resource from my browser. And if necessary, hit "refresh" until the browser is displaying the same javascript code as I have on the server.

In case you have any doubt on what the actual URL that fetches your Javascript file is, the Firefly plugin for Firefox can show each URL fetched as well as the data itself. I think IE has something similar, but I forget.
 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:I'm sorry. I've got a bad attitude. Everybody wants me to pay them, but they expect me to work for free and it tends to sour me even on places where I voluntarily work for free. Meaning that there's a limit on how much effort I put into this stuff. Usually that means I don't bother to run foreign examples or read sample code that takes up more than one screen. Nothing personal.

I've done what I described many times over the last 5-10 years - sometimes even getting paid for it. So there's nothing wrong with the basic concept.

It did occur to me that something I cannot reproduce may be causing you problems, though. If your browser is caching your Javascript file, then the reason it doesn't work is that what your browser is executing is stale code that doesn't match what's on your server.

The trick I use to force a refresh is to directly request the Javascript resource from my browser. And if necessary, hit "refresh" until the browser is displaying the same javascript code as I have on the server.

In case you have any doubt on what the actual URL that fetches your Javascript file is, the Firefly plugin for Firefox can show each URL fetched as well as the data itself. I think IE has something similar, but I forget.


Sorry Tim, I really do appreciate your help. :)

I was only suggesting you perhaps check out the actual code from probably the most popular JSF book out there. I'm just curious if you (anyone) can get it working as written. I assumed, possibly incorrectly, that you already had this book being that you're on this forum. :)

I don't have time to work on this a lot more either as I'm trying to learn JSF in my "spare time".

Frankly, I really wasn't expecting you to be the only person replying to my post. My belief was that JSF was super popular, like Spring, and others would jump in and say: "hey, you just need to ...." to get this working.

Therefore, I'm putting the JSF book on the shelf until I have more time or until I have a project that demands it.

Thanks again.

- mike
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm afraid that one of the things I had to do when the market got tight was stop buying books. An example of how, while wealth has yet to meaningfully trickle down in the 30-something years since that concept was first proposed, that poverty bubbles up pretty darned fast. The money I cannot spend on books becomes income not received by the book authors and publishers (some of which are JavaRanch regulars. Sorry guys.)

I do not think that your real problem is JSF-related. In fact, as I've said, it's probably owing to your browser not having caught up with the server-side JS code changes, and that's a problem that happens everywhere, not just in JSF. So don't write off JSF just on that account.

My own observations is that JSF has its adherents, but that there's a lot of legacy code built on Struts - despite the fact that JSF was in part designed by some of the authors of Struts to overcome some of Struts shortcomings. Then there's Spring Web, frameworks such as Wicket, and specialty stuff like Cocoon.

What's in use tends to depend on what's in fashion in your shop, which in turn tends to be influenced by what's popular in your town.
 
Mike London
Ranch Hand
Posts: 1441
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:I'm afraid that one of the things I had to do when the market got tight was stop buying books. An example of how, while wealth has yet to meaningfully trickle down in the 30-something years since that concept was first proposed, that poverty bubbles up pretty darned fast. The money I cannot spend on books becomes income not received by the book authors and publishers (some of which are JavaRanch regulars. Sorry guys.)

I do not think that your real problem is JSF-related. In fact, as I've said, it's probably owing to your browser not having caught up with the server-side JS code changes, and that's a problem that happens everywhere, not just in JSF. So don't write off JSF just on that account.

My own observations is that JSF has its adherents, but that there's a lot of legacy code built on Struts - despite the fact that JSF was in part designed by some of the authors of Struts to overcome some of Struts shortcomings. Then there's Spring Web, frameworks such as Wicket, and specialty stuff like Cocoon.

What's in use tends to depend on what's in fashion in your shop, which in turn tends to be influenced by what's popular in your town.


Good points all.

Thanks Tim.

-- mike
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!