How to separate filter definitions from the createRouteExpressions.groovy script code ?

iFountain Forum is no longer in use. Support functionality is moved to iFountain Issue Tracker. You are not allowed to post a new topic on this forum, please create a new ticket on iFountain Issue Tracker. You need to create a new account and login to use issue tracker.

Posted November 30th, 2007 by Anonymous

In our environment, an administrator will create the predefined filters that are currently defined in the createRouteExpressions.groovy script.
To avoid exposing both the data (the filters) and the script code, is it possible to separate the filters definition in a dedicated file ? And use a kind of "include " in the script ?

The script used to create

On November 30th, 2007 berkay says:

The script used to create the route expressions is not "special" in any way. It's role is to create objects in the RapidInformer repository to store the expressions to be used by the simplified UI.
This particular script uses the data defined within the script but a different script can be written that reads the information from a file and do the same.
Another, may be better option is to create a UI to define the expressions. This can be a tab in the admin UI or a separate one. As demonstrated with simplified UI and the configuration wizard in the latest release, RapidInformer now provides mechanism to create custom web pages that interact with the RapidInformer server via the web API easily, so creating another web page to create objects is something that can be done during implementation of the project as the needs may be different for different projects.
We'll look into what the best way to separate the configuration from the script may be.

Groovy scripting language

On November 30th, 2007 PinKin says:

Groovy scripting language allows accessing classes from other files. In order to separate the rules to a separate file, we can use "package/import" capability.

In summary; we have to
- remove the configuration part from the calling groovy file
- enclose the configuration part as a class in a separate file. Note that the class and file names are the same.
- define the individual configuration variables as "public static"
- specify the package name in the new file. Refer to the sample files to learn how to define a package name
- import the class with the package name in the calling groovy file. Refer to the sample files to learn how to import the class
- modify the references to configuration variables using the class name in the calling groovy file

Please review the createRouteExpressionsForGroups_2.groovy and RuleConfig.groovy files which are commented to explain the implementation details.

How about using an xml

On November 30th, 2007 berkay says:

How about using an xml configuration file and gpath to parse it in the groovy script as a next step?

The RuleConfig public

On November 30th, 2007 pdunon (not verified) says:

The RuleConfig public package is fine, but I would put the:
config = ["Public":RuleConfig.publicConf, "Group1Name":RuleConfig.conf1, "Group2Name":RuleConfig.conf2];

in the public package as well, so that the Administrator can create new groups without editing the createRouteExpressions script.

XML would be nice as well, assuming that it does not add an additional filter definition syntax to learn.