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?
