godbout / alfred-workflow-config
Manage settings easily for your Alfred 3 or 4 Workflows.
Installs: 2 367
Dependents: 0
Suggesters: 0
Security: 0
Stars: 3
Watchers: 3
Forks: 0
Open Issues: 0
Requires
- php: ^8.0.2
- adbario/php-dot-notation: ^3.1
Requires (Dev)
- codedungeon/phpunit-result-printer: ^0.32
- phpunit/phpunit: ^9.5
- scrutinizer/ocular: ^1.8
- symfony/yaml: ^5.0
README
Easily read and write config settings for your Alfred 3 or 4 Workflow. We took care of the boring stuff for you.
Installation
composer require godbout/alfred-workflow-config
Usage
Import the class:
require 'vendor/autoload.php'; use Godbout\Alfred\Workflow\Config;
Then you can start save settings. Use dot notation for nested settings:
Config::write('language', 'english'); Config::write('workflow.user.name', 'Guill');
Read settings:
$language = Config::read('language'); $userName = Config::read('workflow.user.name');
You can provide a default config for your workflow. It will only be saved if no config is found:
Config::ifEmptyStartWith(['version' => 1.0, 'enabled' => true]);
Usage in your tests
Set the Alfred Workflow Data environment variable
The package uses an environment variable set by Alfred to determine where to create and store your data. If you are not using this Config class through a script that is called by Alfred (like in your tests, for example), then you need to set that environment variable. Use putenv("alfred_workflow_data=./where_you_want_to_store_alfred_data");
before writing or reading your settings.
Destroy the Config between tests
The Config
class is a singleton. This allows me to provide you with a very simple and nice to use API. It works great when being used by Alfred calling your Workflow script, but not so much with testing. If you're using the Config
class in your own tests, you have to destroy the singleton between each test. You can do it easily like this:
protected function tearDown(): void { parent::tearDown(); Config::destroy(); }
This will make sure that your next test starts with a virgin Config
.
ArrayAccess
There is none. We don't keep an array of settings internally, so there's no way to implement completely ArrayAccess. You could read settings through an array notation but not add a new setting, so the whole ArrayAccess implementation has been put to sleep.
Behind the scenes
- We create the Alfred Workflow Data folder if it doesn't exist.
- We create a
config.json
file and store the settings, well, in pretty json. - We directly read and write to the config file, so even if your workflow crashes after, your settings will be saved as soon as you call the method.