Download the PHP package dotink/jin without Composer

JIN - Jsonified Ini Notation

JIN is data format which uses the structure of an INI file with JSON-like values.

It is a simple and informal language which is most suitable for confgiruation data and settings. It works best as a metaconfiguration or schema configuration of sorts, but can also just give rich type and object support to something as simple as a .env file.

In some ways it is similar to TOML (https://github.com/toml-lang/toml), but does not have a formal specification. Parsing rules can best be described as follows:

• File structure is that of an INI file
  • key = value
  • [section]
  • ; comment
• Values are JSON-like with the following differences
  • Escaped character, e.g. \n, \b, \t are not supported
  • A single \ does not need to be escaped

Basic Usage

Calling get() on the collection will return the full parsed data as an associative array.

If you'd rather work directly with the collection you can leave off the get(). You can see more documentation about the collection at (https://github.com/adbario/php-dot-notation):

Using the collection directly will allow you to use the "dot notation" to reference and retrieve specific values, as well as to supply defaults if they don't exist:

You can, additionally, preserve stdClass objects in parsed JSON by passing FALSE to the second parameter:

The Language

A Simple Field

Strings don't have to be quoted, but can be:

Integers are converted to the proper type automatically:

Floats too...

Booleans and NULL values are case insensitive:

Multi-Line Text

Comments

Comments are allowed anywhere in a value, so it is important to keep in mind that anything after an ; character is going to be cut off.

JSON-like Values

Arrays are defined literally:

Objects are also defined literally too:

Both can span multiple lines and contain comments:

Differences

Although values can be JSON-like, they are not, strictly speaking, JSON. The major difference is that they do not support JSON's built in escaped characters, so you cannot use \n or \t. On the bright side, you do not need to escape a backslash:

Sections

Sections provide an alternative to JSON object structures. Note, sections are never parsed as stdClass objects, but will always return associative arrays.

Sub-Sections

You can add sub-sections by separating the previous category name by a dot. This is extremely useful for keyed configuration values with repeating data, for example, imagine a database config with multiple aliases connections:

Section References

You can reference a parent section for shorter section names.

References can be stacked to refer to sub-sub-sections. Reference stacking always begins from the last section defined without a reference:

Environment Variables

You can get values from the environment.

And provide defaults when they are not set:

Native Language Values

You can use native language functions (in this implementation, PHP):

You can add context to the parser for access to variables as well:

Then access/use them as you'd expect:

Custom Functions

You can add custom functions by passing an array of callables keyed by the function name as the second parameter to the parser:

Then use them as you'd expect.

Note, you can overload the env() and even the run() function, however, overloading structures such as map(), def(), inc() will not work.

Templates

Templates provide a powerful way to duplciate complex data structures with different values:

Templates can also be used to create arrays of non-keyed objects:

Testing

Addendum

JIN was originally written as a way to configure a data mapper ORM. It is a very flexible and intuitive language, but it may not make sense in all cases. It is strongly recommended that if you are using it for frequently accessed configurations (like during runtime) that you serialize and cache the resulting collection rather than parsing it on every load.

Editor Support

There is a hobbled together grammar file for Atom which can be found here:

https://github.com/dotink/atom-language-jin

Because of its similarity to TOML, TOML syntax highlighting also tends to look well. You can alternatively try JS/JSON syntax highlighting, but your mileage may vary depending on syntax highlighting implementations.