No sooner is 0.1.4 out for general availability, but 0.2 rears its head again. While some of the features planned for 0.2 are already implemented (they will be covered soon), a very extensive and un-expected enhancement has been made.
The biggest change coming in 0.2 is the complete re-design of the CLI layer. This will only affected command line programs and daemons.
First the bad news: Unfortunately owing to the nature of the re-design 0.2 is not compatible with 0.1.X. Any applications or daemons will need to be re-built.
BUT - good news! Re-building is not as bad as it sounds. The existing Scorpio CLI tools have been re-built in only a few days. At the time of writing both generator and mvcGenerator remain but all the others have been ported already. In fact the re-design highlighted many issues with the existing apps and have allowed them to be refactored far more efficiently than would have otherwise been possible.
So what are the major changes?
Well, instead of a hierarchy like: cli -> cliApplication -> yourApp or cliApplication -> cliDaemon -> yourDaemon, there is now a concrete cliApplication class. This does not need to be extended anymore - but it is for daemons. cliApplication now contains all the signal handling code. cliProcessControls remains largely un-affected. cliDaemon has been totally overhauled and now has an execute() method which has to be extended.
And now the really interesting part: the CLI has acquired the cliRequest (previously cliArguments) and cliCommand. cliRequest now differentiates between switches (-T -b -v) parameter toggles (--my-var=foobar) and arguments (action name something). While parameters and arguments are handling together, switches are held distinctly separate. The cliRequest is passed to a cliApplication and is dispatched. This is where the cliCommandChain and cliCommand come in.
cliCommandChain is as it sounds, a set of cliCommands. This is what now makes up the cliApplication. Each command is a small compact unit that can be switched into and out of an application making it possible to share similar tasks between apps. cliCommand is the execution unit. Ideally it performs only a single action, but it can easily forward to another command (if it is available). Further a cliCommand can have its own command chain of further actions.
Lastly: cliApplication has a cliApplicationListeners object that can have additional listeners attached. A cliApplicationEvent can be fired to these listeners to engage some other activity. Currently planned are an emailer and a logger - yes the cli layer is no longer dependent on systemLog (except for cliProcessControls which are outside the scope of cliApplication) for logging. Logger is already implemented and is used byt the existing apps.
A whole set of default commands will be available including a 'Help' command that formats help information including aliases (triggers), arguments and more. Help has been extended and can now provide additional information about a command such as if it has a command chain, then these commands are the parents possible values so will be presented when the help is called. Help can now be called as myApp.php help
All in all it is a major enhancement that provides for much richer, lighter applications with a far higher ability to re-use code. For example: the testSuite.php had many methods that should not have been in the app, but in library objects. Now that this refactoring has been done that code could be used to power a web-based test suite. It is similar to the wurflParser and the other tools.
This work is licenced under a Creative Commons Licence.