Chrysal is a library to express and manage external configurations expressed as JSON files. Chrysal is purely static, it means that given a list of items, a reader class is generated that manages the conversion between the two worlds (what the end-users is declaring and what the application needs). At run time a generated Chrysal configuration can be a subclass of a domain class, subclass of ChrysalConfiguration. This way we can define behavior that will not be lost during the recompilation of the Chrysal configuration (the one based on the actual description).
- Chrysal creates at compile-time a reader that is responsible for mapping end-user expressed configurations to their internal representations (for example a 'a/b/c.html' into a file reference object).
- In addition at run time a configuration object can customize the default behavior of the generated reader.
- Finally the configuration developer can extend Chrysal to support new data.
Here is an example of a configuration. This configuration is the one of a pillar project. The end user specifies different values for given entry.
{
"base_url": "/booklet-ReflectiveCore/html",
"site_name": "Pharo Book",
"title":"A simple reflective object kernel",
"attribution":"Stéphane Ducasse",
"series": "The Pharo TextBook Collection",
"keywords": "project template, Pillar, Pharo, Smalltalk",
"language": "en-UK",
"epub-id": "urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809",
"tocFile": "index.pillar",
"latexWriter" : #'latex:sbabook',
"newLine": #unix,
"htmlWriter": #html
}
Chrysal supports the conversion of elements (file, new lines, custom domain specific,..) entities from a textual format to Pharo object.
It supports composite and list of items too. Item descriptions are subclasses of ChrysalItem.
For example the NewLineConfigurationItem manages how the word #unix will be converted into the correct platform specific encoding.
This logic is defined in the class NewLineConfigurationItem.
ChrysalItem subclass: #NewLineConfigurationItem
instanceVariableNames: 'defaultDomainObject defaultKey'
classVariableNames: ''
package: 'Chrysal-Model'
The developer of a specific configuration will assemble together a list of configuration item. This is this list that will describe how the actual configuration will be managed. This list will be interpreted and eaten by a reader builder to generate a specific reader.
Here is typical configuration description.
itemDescriptionForXX
"just a simple description of items for the tests"
^ {(StringConfigurationItem new
propertyName: #title;
default: 'my super cool book';
yourself).
(NumberConfigurationItem new
propertyName: #headingLevelOffset;
default: 0;
yourself).
(BooleanConfigurationItem new
propertyName: #verbose;
beTrueAsDefault;
yourself).
(FolderConfigurationItem new
propertyName: #outputDirectory;
default: 'build').
(FileConfigurationItem new
propertyName: #mainDocument;
default: 'book').
(FileConfigurationItem new
propertyName: #latexTemplate;
default: '_support/templates/main.latex.mustache').
(FileConfigurationItem new
propertyName: #latexChapterTemplate;
default: '_support/templates/chapter.latex.mustache').
(FileConfigurationItem new
propertyName: #htmlTemplate;
default: '_support/templates/html.mustache').
(FileConfigurationItem new
propertyName: #htmlChapterTemplate;
default: '_support/templates/html.mustache').
(NewLineConfigurationItem new
propertyName: #newLine;
defaultIsUnix).
(SymbolConfigurationItem new
propertyName: #latexWriter;
default: #latex:sbabook;
yourself) "may be we should turn it into a Pillar specific item that convert to a specific class".
(CompositeConfigurationItem new
propertyName: #printerComposite;
default: #ChrysalCompositeDomain;
fields: #(level renderAs capitalization numbering headerSize);
yourself).
(CompositeConfigurationItem new
propertyName: #convertedComposite;
default: #ChrysalConvertedCompositeDomain;
fields: #(newLine htmlTemplate title);
yourself).
(ListConfigurationItem new
propertyName: #levels;
default: #OrderedCollection;
element: 'printerComposite';
yourself).
(PathConfigurationItem new
propertyName: #relativeSimple;
default: 'simple';
yourself).
(PathConfigurationItem new
propertyName: #relativeComplex;
default: 'simple/simple1';
yourself).
(PathConfigurationItem new
propertyName: #absoluteSimple;
default: '/simple';
yourself).
(PathConfigurationItem new
propertyName: #absoluteComplex;
default: '/simple/simple1';
yourself)
}
The configuration builder will consume a configuration description as shown above and produce a configuration reader.
Here is a typical way to invoke the builder.
ChrysalConfigurationBuilder new
defineConfigurationClassNamed: #ConfigurationForXX packagedIn: 'Chrysal-Tests';
withDescriptionItems: ConfigurationDescriptionForXX itemDescriptionForXX
Note that it will generate a class and its associated comments so that we can regenerate it too.
Pillar extends the ChrysalConfiguration (run time class) to be able to perform extra treatment.
ChrysalConfiguration subclass: #ChrysalPillarishConfiguration
instanceVariableNames: 'printer'
classVariableNames: ''
package: 'Pillar-Chrysal'
ChrysalPillarishConfiguration >> postTreat
(self propertyAt: #levels ifAbsent: [^ self ]) do: [
:levelSpec |
| instance |
instance := (self printer printerSpecFor: levelSpec renderAs).
instance fillFromAnother: levelSpec.
self printer level: instance n: levelSpec level.
]
Note that neither the items (subclasses of ChrysalItem and ChrysalItems), nor the builder will be used at run time.
There you can package your description outside of Chrysal. This is why you can also store a description configuration in a textual format.
The only dependency needed at run time is the Chrysal-Runtime. This package is minimalistic and it only contains the class ChrysalConfiguration that will be extended by the generated configuration reader produced by the builder.
Since a configuration item describes information that will be used to generate code, it acts as a static data (from that perspective it can be perceived as data to be fed to a macro expansion engine).
JSON configurations consider the following as literals and not strings: number true false symbol string. Therefore the conversion is not needed.
To extend the item hierarchy, a new class should defines the methods: defaultDomainValueString and domainValueConversionString.
defaultDomainValueString
"Returns a string representing the default value but as an object once imported in Pharo and not a string used by the writer of a configuration."
...
domainValueConversionString
"Returns a string converting a string as written in the configuration file to a pharo object.
Note that this method is like the body of a macro that will be expanded in the configuration class: here aValue is the name of the parameter of the generated method.
For example for fileConfigurationItem (inputFile),
the result of the method will be used in the body of the following generated method
convertInputFile: aValue
^ (FileSystem workingDirectory / aValue)
Parameter of the item like baseline should be accessed via self nameOfProperty"
^ '^ aValue'
Read the class, BooleanConfigurationItem for a simple case and NewLineConfigurationItem for a bit more advanced case.
Metacello new
baseline: 'Chrysal';
repository: 'github://Ducasse/Chrysal';
load.
spec
baseline: 'Chrysal'
with: [ spec repository: 'github://Ducasse/Chrysal' ].
- Path management should be revisited.