Do you know what I hate about Regular Expressions in most languages? The fact that you have to escape things. Regular Expressions are complicated enough without then having to worry about escaping.
Flex doesn't have this problem though as you can code a regular expression in-line. It recognises anything starting and ending with a solidus (forward slash) as a regular expression and in the background (pre-compiler stage I suppose) converts it to RegExp object. http://livedocs.adobe.com/flex/3/langref/RegExp.html Obviously we're not having any precompiler stage in Pivot, but since we're using XML would it be possible to allow the pattern to be specified in a CDATA block? Then there's no escaping required. For example, lets say we want the user to enter a quoted string, the regex would be: (["'])(?:\\\1|.)*?\1 (from : http://blog.stevenlevithan.com/archives/match-quoted-string) Hopefully you can see the problem with that, if passing it in to an XML attribute... the XML is broken because of the double quote: <TextInput> <validator> <validation:RegexTextValidator pattern="*([*"'])(?:\\\1|.)*?\1" /> </validator> </TextInput> To fix it: <TextInput> <validator> <validation:RegexTextValidator pattern="*(["'])(?:\\\1|.)*?\1*" /> </validator> </TextInput> But how ugly is that? " is not part of the regex and makes the regex look even worse. My proposal: <TextInput> <validator> <validation:RegexTextValidator> <validation:pattern><![CDATA[ *(["'])(?:\\\1|.)*?\1* ]]></validation:pattern> <validation:RegexTextValidator> </validator> </TextInput> The pattern would need to be 'trimmed', but at least that aspect is hidden from the developer and no need to do any escaping, etc. Any thoughts? Would this be useful, or is it too much at this stage? Cheers, Chris 2009/3/26 Greg Brown <[email protected]> > Hi Noel, > > While attempting to add a validator example to the Kitchen Sink demo, I > noticed a couple of things that still need a bit more work: > > 1) The validation classes need more Javadoc. I'll admit that we're pretty > lax about method Javadoc a lot of the time, but we do try to make sure that > every class has at least a minimal description. Otherwise, the documentation > tends to look a bit unprofessional. > > 2) Each concrete validator should have a no-arg constructor and bean > properties for configuring its behavior so it can be used in WTKX. For > example, RegexTextValidator should have a "pattern" property: > > Pattern getPattern() > void setPattern(Pattern pattern) > void setPattern(String pattern) > > The string setter allows us to use it from WTKX like this: > > <TextInput> > <validator> > <validation:RegexTextValidator pattern="[0-9]"/> > </validator> > </TextInput> > > WTKX automatically handles setters for primitive types (via > BeanDictionary), so you don't need to provide String overloads for those. > However, any non-primitive setters will require a String overload. > > We'd very much like to get these updates in before we release version 1.1. > Do you think you will have time to do it in the very near future? > > Thanks, > Greg > > >
