Originally posted by K Varun:
I have fixed patterns for many of the fields used in my application. There also regular expressions corresponding to each pattern to handle scenario where it's needed.
[...]
Just to give an example, right now for SSN I have pattern as : ###'-'##'-'#### and regex as "^\\d{3}-\\d{2}-\\d{4}$",
but I wont like to remove the harcoded regex and want to generate it on run-time.
hm. in the general case, this could be somewhat difficult, actually. in your specific case it might not be that hard, depending on what constraints your patterns are under; if it turns out that they can't get very complex, it should be doable. it'll take some effort, but it shouldn't be any huge project.
you'll need one function to quote any special characters that might need quoting for regular expressions, another for translating your pattern character into regular expression entities, and a third for collapsing sequences of regular expressions into regexp-quantifier pairs.
in other words, first you'd want to run your pattern through a "quoter/unquoter" that would take things like ".", "[", "$", and so on, that might occur in your pattern, and escape them so they'd pass on through to the regex. (also, you might want to remove things from your pattern that you don't want in your regex - such as the single quotes around the dashes in your example - in this step.) then you'd run that through a replacer, that would translate from "#" to "\\d", for example. finally, you'd want to do a form of run-length compression on that in turn, to translate "\\d\\d\\d" into "\\d{3}".
actually, come to think of it, i might have gotten my steps #1 and #2 backwards; perhaps you really want to do it the other way around, or even combine those two into a single step. experiment, do some
testing.
if your patterns can get truly complicated, you might have to do a full tokenizer/lexer to break them down into syntax elements and translate those abstractly. that'd be a considerable project, unless you could find just such a lexer already written and coopt it.
any which way you do it, even if you manage to find some helpful classes and methods somewhere in the
Java API (i don't know of any off the top of my head, but the Java API is much larger than'll fit in the top of my head), you're looking at a fair-sized project - i'd guesstimate maybe a few hundred lines of code. i doubt it'll exceede a thousand lines, unless your patterns can get complicated. if you decide to do this, let us know how it turns out, OK?