myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Hoover" <>
Subject RE: [Trinidad] Input Text Format That Uses A Mask
Date Wed, 06 Jun 2007 18:55:34 GMT
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: <>

-----Original Message-----
From: Mike Kienenberger []
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?

On 6/6/07, William Hoover <> 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 []
> 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 <> 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
> >
> > 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 []
> > 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
> >
> >
> > 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:
> >
> > ... would be important for that.
> >
> > I'd love to see this functionality!
> >
> > -- Adam
> >
> >
> > On 6/5/07, William Hoover <> 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
> > > <>). I
> > > would like to know what the process/procedure is to commit this component to
> > > the sandbox?
> >
> >

View raw message