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?