Packfire Framework came a long way to be where we are today. The framework now empowers research projects as back end data servers and controllers, such as the Travel Assistant for the Visually Impaired (TAVI).
With the will for continuous progress, Packfire will be releasing a version 2.1 on 15 April 2013 sporting the following new upgrades, improvements and new features:
- Better IoC dependency distribution using Packfire FuelBlade
- Config and Flash message view filters
- Security Analysis page
- Backend Administration Webpages
- Improved Composer package loading and integration
- several minor bug fixes and greater code testing coverage
- minor code speed up and improvements
First of all, Merry Christmas to all (:
More code, less talking. That’s what happened for the past few weeks. Nevertheless, we came up with great projects that we are sharing open source on Github. These projects were created to solve many challenges that web developers or software engineers face commonly. Here are some of the projects:
[CLI] means that the project runs as a command-line interface application in the form of a PHAR binary. [Composer] represents that the project can be installed and used by others through Packagist and Composer installation.
PDC for PHP: [CLI] a smart little worker that helps you to check for missing class dependencies by analyzing your source code and checking against PSR-0 namespace and autoloading. Makes you code faster as you spend less time trying to fix a misspelled namespace.
Packfire Torch: [CLI] a web asset management tool for you to keep images and JavaScript libraries out of your version control. Torch installs web assets from any source just like how Composer install components.
Packfire Options: [Composer] A PHP-implementation of NDesk.Options (C#) using Closures and callbacks to help you effectively parse CLI arguments across platforms.
Packfire Concrete: [Composer] A small library that provides toolset for PHAR compilation similar to how Composer does it. Used by PDC and Torch to compile themselves into PHAR binaries. CLI version coming soon.
We all know that in a PHP script, you can return an exit code CLI-style using the exit language construct: exit(2); Exit codes have been very widely used in CLI tools such as Git or apt-get to tell the calling script that there may be an error of sort and the operation was not successful. This makes a great experience for an end-user.
However, the exit call assigns the exit code and immediately terminates the script. Sometimes you just want to set the exit code, do some work then terminate the script and that can’t happen.
The solution is to use shutdown hooks (the question was about Java, but thanks to Packfire Framework’s ShutdownTaskManager you can quickly do the same).
$this->service('shutdown')->add('exitCode', function(){
exit(3);
});
doMoreWorkAfterSettingExitCode();
This allows you to do more work after setting the exit code to your PHP script. Sweet and simple!
