aspose file tools*
The moose likes JSF and the fly likes Change focus based on the input Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Change focus based on the input" Watch "Change focus based on the input" New topic
Author

Change focus based on the input

dinesh laxman kumar
Greenhorn

Joined: Jul 11, 2012
Posts: 19
Hi,

I have a form containing two input text fields.

Requirement -
In the first field if no value is input or is left empty and skipped focus to the next input text field,
- Change the focus to the first input text field
and
It should prompt an error message on the first input field such as
- "Enter the value in this field first"


Thanks in advance
Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

Hello!

This article can be helpful:
http://balusc.blogspot.com/2007/12/set-focus-in-jsf.html


True person is moral, false is right!
dinesh laxman kumar
Greenhorn

Joined: Jul 11, 2012
Posts: 19
Thanks Levytskyi but,

Sorry for providing insufficient information.

I need to do it Primefaces
Tried using - #{p:component('cmpId')}.focus(), Did not work

Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

Hello!

Can you use javascript function to focus your element. That article gives this method to focus component:

If it is not possible to focus programmatically then maybe you can focus via javascript!
dinesh laxman kumar
Greenhorn

Joined: Jul 11, 2012
Posts: 19
Sorry again,

As per requirement, I am not supposed to use separate javascript functions in XHTML pages

Would like to know if the method which I used earlier is right,
Or any docs, references in that matter would be of great help.


Volodymyr Levytskyi
Ranch Hand

Joined: Mar 29, 2012
Posts: 505
    
    1

Hello!

Maybe it is worthy to set this question or look for the answer at http://forum.primefaces.org/
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

There are Requirements and then there are "REQUIREMENTS". One (hopefully) makes your software more standardized and easier/less expensive to maintain. The other is what you get when people hand down ironclad edicts based on thinking they know more than they do. That sort of requirement makes software more expensive, not cheaper. I can help you with the first sort of requirements. The second is less about effective use of technology and more about asserting brute raw power and the only help I can give in cases like that involves updating the CV.

You'll see me saying a lot of "Don't do this" and "Don't do that" in my role as contributor to these forums. Most of the time I'm basing those admonitions on what I've learned the hard way. Not everyone takes my advice, but then again, they're not required to. Nor is it uncommon for me to withdraw an objection once I see what the bigger picture is. It's true. Rules are made to be broken. The key is in knowing when to break them, which is why they're rules to begin with. It's the difference between inexperienced amateurs fumbling around and trying to force things to be the way they think they should be and experienced professionals making calculated decisions. Personally, any time I can do the impossible within the rules I count it a greater victory than doing the same thing by building up an elaborate run-around.

The preceding editorial was provided gratis. Next up, my rules on JavaScript in JSF (for what they're worth).

1. Inline JavaScript, like complex EL expressions are a to debug. It's virtually impossible to set breakpoints or trace them. So my rule for inline javascript is to keep it simple. If my needs are complex, I put a function call in instead and do the work out-of-line.

2. Out-of-line JavaScript can be done in 2 different ways. You can place a block of JavaScript in the JSF xhtml or you can create a separate stand-alone JavaScript file.

A) JavaScript in xhtml is quick-and-dirty with the accent on dirty. I use it to prototype, but try to avoid it for the final code. The advantage here is that you have fewer source (but larger) files to juggle. The disadvantage is that JavaScript in XML (including xhtml) files is treacherous stuff. Too many JavaScript constructs look like bad XML to an XML parser. So the only real safe way to deal with it is to put the JavaScript inside a CDATA inside a script element (and for the truly paranoid, put that inside a f:verbatim element).

B) An external JavaScript file makes the source tree more complex (more files), but the individual files are simpler. Also, your IDE may be able to intelligently edit the JavaScript code itself if it knows that it's really JavaScript (because it's in a .js file) instead of some sort of weird XML. Although the traditional locations for scripts is a catch-all "/scripts" directory, I find that putting the .js file next to the .xhtml file works better, since any container-based security can often use the same filters to protect both View Template and script. An additional advantage of a separate script file is that (depending on configuration), the script can be cached on the client, so that downloads of view updates will be smaller/faster.

OK. Now on to the problem itself.

I had trouble reading this, as there are at least 2 interpretations. One is that the required field must be populated before the second field at the time of entry. The other would be that an attempt to submit the form would then assert the need for the required item and direct the input focus there.

At first, I thought this was about submitting, but now I'm inclined towards the first explanation. For that one, you should initiate logic in an onfocus event in the second control The logic would test for data in the first control, and if not found, throw up an alert box, followed by a focus() command. So, something sort of like this:


Remember what I said about keeping the inline JavaScript simple. And what to do if you are forbidden. Life's too short for unnecessary suffering.

The requireInput script has a pseudo-code something like the following. If you have jQuery at your disposal, it can make the logic simpler.


Customer surveys are for companies who didn't pay proper attention to begin with.
dinesh laxman kumar
Greenhorn

Joined: Jul 11, 2012
Posts: 19
Thanks Volodymyr,

And Tim, one of the best gratis ever received
Since I am not well acquainted with xml and parsing methodology,
Will take this discussion to my seniors



Cheers
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Change focus based on the input