Deactivating validations

[Jesus Schneider]

Hi!
I'm a beginner in JSF. I was making some tests (netbeans, JSF 2.1 + primefaces) with a typical login example:

<h:form>
<p:inputText id="elnick" value="#{controlador.nick}">
        <f:validateLength minimum="7"  maximum="25" disabled="#{controlador.comprobaciones}"/>  
</p:inputText> 

<p:password id="elpass" label="labelpass" value="#{controlador.pass}" > 
     <f:validateLength minimum="7" maximum="20"  disabled="#{controlador.comprobaciones}"/> 
</p:password> 

<p:commandButton id="botonlogin" action="#{controlador.login()}" value="Login" update="logingrid" /> 

<p:commandLink id="linkperdido" action="#{controlador.forgotPass()}" value="FORGOT MY PASSWORD" update="msgs" actionListener="#{controlador.desactivaListener(event)}" /> 
<h:form>

public void desactivaListener(ActionEvent event) {
    comprobaciones=true;
}

public String forgotPass()   
{ 
    comprobaciones=false;
    FacesContext.getCurrentInstance().addMessage(null, new FacesMessage(FacesMessage.SEVERITY_INFO, "A mail has been sent to that user.", null)); 
    return "";
}

As you can see in the code below I have some components to get a user/password with a minimum lenght, and a commandLink that is intended to retrieve the password via mail. The problem is that I cannot use the commandlink if the lenght of the user and password are not OK.
I have tried to deactivate validations via the disable property with an action event (goes first and changes a boolean to deactivate) and the action (goes later, activate validations) but it doesn't work.
Can someone help me with this question?

[Tim Holloway]

¡Ay, Caramba! I hate "typical login examples". Yes, I know that every J2EE book under the sun has one, but user-written logins are the first stage in being hacked. I have worked with J2EE for a very long time and I have never encountered a system that had a user-designed security system that was actually secure. J2EE defines a security framework that is built right into the server, fully-debugged and operational these many years. I recommend using it.

As far as considering your code as a general JSF exercise, here are some things to note:

1. JSF backing beans are not Controllers. They are Models. So naming a JSF backing bean "xxxController" (or controlador) is technically incorrect.

2. EL is not intended as a full-scale programming language, nor should "program code" appear on your View definitions. That breaks the Separation of Concerns contract for MVC. More importantly, it makes application maintenance much harder. In other words, "#{controlador.login()}" is not the way you should bind a login action method to a backing bean. It's just "#{controlador.login}". JSF already knows that a call will be made, and there is a significant difference between an EL function call and an EL resource reference expression.

[Jesus Schneider]

Thank you for your notes but... you didn't answer my question at all!!
Please, some help with the deactivation issue?
Thanks in advance!

[Tim Holloway]

Sorry about that. JSF is designed specifically to ENSURE that submitted data is valid. If it is not valid, the bean will not update and the actions will not fire.

The only way to "deactivate" that mechanism is to not attempt to submit invalid data.

You can do that in 2 ways:

1. Place the Submit control on a separate form, since only one form gets submitted and if the bad data is on some other form, no problem.

2. Use the "immediate=true" attribute on the Submit control (commandLink). When you specify a submit as immediate, no data is submitted, therefore it isn't validated.

Option #2 is the one to use for your particular problem.

[Jesus Schneider]

Ay caramba!!! It works perfectly!!
Thank you!!!