Continued experimentation with the INIX “ini” file format. I take the original post code and add an alias feature.
In three prior posts I presented a very simple metadata file storage approach. Pretty much using the INI file format with the sections as “heredocs.” In original INI format, afaik, the data within the sections were properties only, x=y.
Now I am working on adding the ability for a section of data to load data from another section. The sections to load are indicated by the ‘@’ symbol and then the section path. Multiple sections can be indicated. Though I’m using the term ‘alias’ for this, perhaps a better term is ‘importing’. So far, I can parse the alias from the tag string.
I have not implemented the actual import. One complexity left to solve is recursion. If this section imports another section, what if that section imports others sections?
Alias use case
Since currently the Inix file format is being used for test data, aliasing allows reuse of data without duplication, i.e., DRY. This is problematic with hierarchical data like JSON or XML, but much easier with lists or maps. Further features like overriding and interpolation would be useful for Java Properties data. The goal would be to eventually support use of the Cascading Configuration Pattern.
[>First] Data in first [<] [>Second@First] Data in second [<]
Now when the data in section “Second” is loaded, the data from the aliased section is prepended to the current section data:
Data in first Data in second
The section tag format is now: [>path#fragment@aliases?querystring]. Note that unlike a URI, the fragment does not appear at the end of the string.
The section ID is really the path#fragment. Thus, the end tag could be [<] or can use the section ID: [<path#fragment]. Example 2
[>demo1/deploy#two@account897@policy253?enabled=true&owner=false] stuff here [<demo1/deploy#two]
The start of a grammar follows, but has not been ‘checked’ by attempted use of a parser generator like Antlr.
grammar Inix; section: start CRLF data end; start: '[>' path (fragment)?(alias)*('?' args)? ']'; end: '[<' path? ']'; path: NAME ('/' NAME)*; fragment: '#' NAME; alias: '@' NAME args: (NAME=NAME ('&' NAME=NAME)*)?; data: (ANYTHING CRLF)*; NAME: ('a'..'z' | 'A'..'Z')('a' .. 'z' | 'A'..'Z'|'0'..'9'|'_');
Source code available at Github: https://gist.github.com/josefbetancourt/7701645
Note that there are not enough tests and the implementation code has not been reviewed.
The test data is:
Groovy Version: 2.2.2 JVM: 1.7.0_25 Vendor: Oracle Corporation OS: Windows 7
- The Evolution of Config Files from INI to TOML
- Groovy Object Notation using ConfigSlurper
- Configuration Files Are Just Another Form of Message Passing (or Maybe Vice Versa)
- INI file
- Data File Metaformats
- Here document
- JSON configuration file format
- Creating External DSLs using ANTLR and Java
- Groovy Object Notation (GrON) for Data
- Cloanto Implementation of INI File Format
- Designing a simple file format
- The Universal Design Pattern