<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<h:outputStylesheet library="css" name="styles.css"/>
<h:panelGrid columns="2" columnClasses="evenColumns, oddColumns">
<h:commandButton type="button" value="Submit Form" onclick="checkPassword(this.form)"/>
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.
Tim Holloway wrote:Come to think of it, I think the proper attribute for that isn't "onclick", it's "onsubmit".
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.
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.
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.