string substitution handler

[hongsudt]

This will allow me to set a variable to a different string based on another string value e.g. s/impt/usc/g

[karlcz]

I think what we need is a "template_pattern" handler to allow a new round of regular expression matches and pattern-group expansion into the environment. Something like:

{
   "handler": "template_pattern",
   "source": "template", 
   "pattern": "regular expression",
   "output": "groups"
}

1. Expand the "source" template to get a source string
2. Match the "pattern" regular expression against source string
3. Add the matching groups dictionary to the environment

The "output": "groups" constant selects the matching groups dict mechanism described in step 3. We could use this as a hook to introduce other output modes in the future, but this matching groups mechanism seems sufficient for any use cases we have in mind now...

[karlcz]

We have been discussing whether this pattern-conditional mechanism should be more general than this. Rather than only supporting conditionally output to the environment when the pattern matches, do we want to recursively invoke a whole disposition chain when the pattern matches? Edit: this allows conditional invocation of any of the built-in handlers including file processing, calls to ermrest, calls to hatrac, etc.

This would require a little more code refactoring but would make the config more powerful. In essence, the current top-level pattern-disposition dispatcher hard-codes a few ideas:

• the source string for the pattern match
• that we execute "first match" and terminate
• that a zero-match rejects a file
• that we start with empty environment and populate with file info and dispatch chain effects

The more general and recursive dispatcher would need parameters to cover the top-level case and also nested dispatch:

• accept an incoming environment to augment instead of always creating a new one
• option to choose source string for pattern matching
• option for first or every match being dispatched (in order)
• option for whether zero-match is an error or OK

From a local perspective, this allows more general if-then trees to be configured. One might argue that we should abandon this whole design and instead provide a library and just let the local custom configuration be a Python script which can use normal control-flow and exception handling, instead of defining this funny conditional execution graph document....

@hongsudt @svoinea @robes @mikedarcy

[svoinea]

This was implemented through the commit 948a7e1d2dac634edf2bc89233810be57623c2e5

Example:

{
    "handler": "template_pattern",
    "source": "template",
    "pattern": "regular expression",
    "output": "groups",
    "relpath_matching": true,
    "if_match": {
        "disposition": [...]
    },
    "if_zero_match": {
        "disposition": [...]
    },
    "failure": "failure"
}

Required attributes:

• source: the string to be matched;
• pattern: the pattern against the string is matched to.

Optional attributes:

• relpath_matching: if present and equal to true, the \ from the string are replaced by / before the match is performed.
• output: if present and equal to groups, the output dictionary is updated with the matched groups.
• if_match: if present, it designates an inner disposition to be executed in case of a match. The inner disposition inherits the caller context (the output dictionary).
• if_zero_match: if present, it designates an inner disposition to be executed in case of no match. The inner disposition inherits the caller context (the output dictionary).
• failure: the action to be executed in case of no match and no if_zero_match attribute.