Extension to autosetup settings and data


#1

The idea is to have an extension (I don’t think it likely makes sense in this form in core) that is able to add data to the database on app (re)-load - especially useful on initial load. It should be possible to easily fill the database with relevant and required settings as well as initial - more or less static - data.

It would use an interceptor that performs the processing postPresideReload.

The following properties file would hold the settings and data (see below).
Custom importers (for complex settings as well as data imports) can be used. It will ship with one custom importer to deal with multilingual settings as well as one data importer for setting up initial security groups. For the settings a generic default importer will be created that can deal with all simple value settings (which most of them are anyway). It would be easily extendable also for custom imports by creating additional importers to be used.
general processing instructions can be defined to globally enable/disable the processing as well as make sure that only data is written once but never overwritten.

It is also imaginable to use a JSON file rather than a properties file. I just find it odd that it’s not possible to add comments to a JSON file which in this case might make sense. Other file formats may fit as well (YAML, …)

/application/config/autosetup.properties

# PROCESSING INSTRUCTIONS
processing.enabled=true
processing.overwrite=false

# ADMIN CONFIG SETTINGS (Preside Admin > System > Settings)
settings.email.server=127.0.0.1
[email protected]

# you can use all other settings which are simple values here, core ones as well as your own defined ones

# custom import: creation of internal language objects and referencing the IDs
settings.multilingual.default_language=en
settings.multilingual.additional_languages=de,fr
settings.multilingual.urls_enabled=true
settings.multilingual.importer=MultilingualSettingsImporter

# DATA IMPORT
data.1.importer=SecurityGroupDataImporter
data.1.args.groups.1.name=System Administrators
data.1.args.groups.1.roles=sysadmin
data.1.args.groups.2.name=Content Administrators
data.1.args.groups.2.roles=contentadmin
data.1.args.groups.3.name=Content Editors
data.1.args.groups.3.roles=contenteditor 
data.1.args.groups.4.name=Formbuilder Managers
data.1.args.groups.4.roles=formbuildermanager

Would this be useful to have? Any ideas for improving it?


#2

as discussed with alex on slack, could also be interested to expand this by building a “content bundles” concept. this would allow to import/export/add/remove bundles of defined data. it might then be useful to add the “origin” to a data record to be able to identify whether the record was added from a content bundle.
use case: apply test data content bundle and later remove all test data at once.

this would then obviously get way more complex, e.g. dealing with assets, more complex relations and removing of data that has dependencies…


#3

Yes, I like this principal though I think there are two things at play here:

  1. settings (which can already be handled in Config.cfc + injected configuration / environment vars)
  2. data

I think however, that the .properties file might be too limiting for initial datasets. Consider data that is more than just a label and might have relationships on other data that is also auto generated from this configuration. Some kind of “content bundle” file format then makes a lot of sense. We could then create conventions around the placement of content bundles so that they auto load, etc.

Any ideas on what that convention should be?


#4

First thought of a data bundle. A simple zip file (perhaps with .pbundle or some such extension), with structure:

./data // each file can contain both array of data + configuration about how to sync it
    some_object.json
    another_object.json
    page.json
    some_page_type.json
./settings // special data for syncing into the system_config object
    settings_category.json
./binary
    // files in here, would need some sort of structure to mirror each 'storage provider used
bundle.json // general info about the bundle, perhaps order in which to import data, etc.

Perhaps also a bundle could be just a directory (i.e. unzipped). This would be more practical for data that would be defined in code as versioning would be cleaner (not just a single binary file changing each time).