Very similar, except this validator would have to add JS calls to the onkeydown event of the component its validating. I'm not sure if this is a good idea?
Atlas Example: <http://www.fci.com.br/maskedit/MaskEdit/MaskEdit.aspx> -----Original Message----- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 06, 2007 2:40 PM To: MyFaces Discussion Subject: Re: [Trinidad] Input Text Format That Uses A Mask How does this compare to validateRegExpr in Tomahawk, particularly if it becomes a validator instead of a component? http://myfaces.apache.org/tomahawk/validateRegExpr.html On 6/6/07, William Hoover <[EMAIL PROTECTED]> wrote: > Point well taken! The component should extend UIXInput instead and renamed > CoreInputMask. Are you are proposing to change this into a validator or > converter instead of a component extension? If it was to use a > converter/validator at what point would it append the JS event calls > (onkeydown, onblur, onfocus)? As of yet it does not address server-side > validation, but it would be fairly easy to implement. Currently, using the > example of a (999)999-9999 mask, and an input of (415)555-1212 the bean would > see exactly what the user input i.e. (415)555-1212 If a converter/validator > was to be used it would be simple enough to strip the mask characters. I > would assume that it would be best to have this as an option because it may > be desirable to maintain the mask? > > > > -----Original Message----- > From: Adam Winer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 06, 2007 12:03 PM > To: MyFaces Discussion > Subject: Re: [Trinidad] Input Text Format That Uses A Mask > > > A few and questions: > - Generally speaking, we don't extend CoreInputText, we just > re-extend UIXInput. The metadata system supports "includes" > for generation, so you don't have to cut-and-paste that much. > One good reason, in this case, is that I assume that this > component doesn't support <TEXTAREA>, just <INPUT> - > so you don't want "rows" or "wrap". > - I'd love to see this as a converter or validator tag that can be > added to an ordinary af:inputText. We'd need a bit of beefing > up of our client-side code JS framework for validators, but > that'd be worthwhile. > - What's the server-side model look like? E.g., when you > have (999)999-9999, does your bean see strings like > (415)555-1212, or do you get 4155551212? Is there server-side > validation to double-check the mask was applied? > - If this is a component, I think CoreInputTextMasked might > be clearer, if the property is named "mask". > > -- Adam > > > > On 6/6/07, William Hoover <[EMAIL PROTECTED]> wrote: > > Thanks for the info Adam! > > > > The component (CoreInputTextFormat) logic is fairly simple and could be > > directly integrated into the CoreInputText, if desired. It extends > > CoreInputText and adds two extra PropertyKeys: "mask" and > > "clearWhenInvalid". The "mask" attribute designates the pattern for which > > will be used to prevent invalid characters at the specified slots. For > > Example, (999)999-9999 would be displayed as (___)___-____ allowing only > > numeric values to be entered where underscores are present (see examples > > below for a more detailed overview). The "clearWhenInvalid" is an option to > > clear the contents (onblur) of the input field when it does not meet the > > mask pattern requirements- default is currently true. The only other logic > > contained in the component is used to make the JS calls: onblur, onfocus, > > and onkeydown. The client script is contained in a namespace called > > "CoreInputTextFormat" so none of the functions will interfere with other > > Trinidad scripts (as you suggested in TRINIDAD-37 it would be nice if we > > had a Trinidad namespace that could register component level namespaces!). > > It does however add a prototype extension to RegExp to allow > > RegExp.escape(someText) preventing recompilation of the escape expression. > > That is it! I don't think there is a significant amount of code to warrant > > a CLA (client script under 200 lines, component logic is trivial). Let me > > know what your thoughts on all of this! > > > > Mask Individual Character Usage and Reserved Characters: > > 9 - designates only numeric values > > L - designates only uppercase letter values > > l - designates only lowercase letter values > > A - designates only alphanumeric values > > X - denotes that a custom client script regular expression is specified > > All other characters are assumed to be "special" characters used to mask > > the input component > > > > Examples: > > (999)999-9999 > > only numeric values can be entered where the character position > > value is 9. Parenthesis and dash are non-editable/mask characters. > > 99L-ll-X[^A-C]X > > only numeric values for the first two characters, uppercase values > > for the third character, lowercase letters for the fifth/sixth characters, > > and the last character X[^A-C]X together counts as the eighth character > > regular expression that would allow all characters but "A", "B", and "C". > > Dashes outside the regular expression are non-editable/mask characters. > > > > -----Original Message----- > > From: Adam Winer [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 05, 2007 7:09 PM > > To: MyFaces Discussion > > Subject: Re: [Trinidad] Input Text Format That Uses A Mask > > > > > > Roughly speaking, you: > > - Create an issue on JIRA > > - Attach a patch > > - If it's a significant quantity of code, file a CLA > > http://www.apache.org/licenses/icla.txt > > > > It's also generally a good thing to talk over the > > design first. I'd thing it'd be great if this were part of > > the client-side validation code, instead of just its > > own code. I think getting this issue fixed: > > http://issues.apache.org/jira/browse/TRINIDAD-37 > > ... would be important for that. > > > > I'd love to see this functionality! > > > > -- Adam > > > > > > On 6/5/07, William Hoover <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hello all, > > > I have created a Trinidad component that allows input text boxes to have a > > > user defined mask for entries on the client (similar to Atlas MaskEdit > > > <http://www.fci.com.br/maskedit/MaskEdit/MaskEdit.aspx>). I > > > would like to know what the process/procedure is to commit this component > > > to > > > the sandbox? > > > > > >
