The sfTaskExtraPlugin
is a plugin maintained by the symfony core
team. It adds a number of useful tasks
to your symfony command line to help streamline your workflow. This plugin is
relatively young, so I will just be discussing those tasks that we'll be using
for today's Plugin Developers
Day. I should also note this plugin requires symfony 1.2.
Plugin Tasks
We now turn our focus to easing the process of creating, developing and
releasing plugins. The following tasks are included in sfTaskExtraPlugin
:
generate:plugin
generate:plugin-module
plugin:package
New Task: generate:plugin
Very much like generate:app
task, the generate:plugin
task creates a basic
plugin directory structure:
$ ./symfony generate:plugin myFirstPlugin
After running this command you should see the following plugin structure in your project's plugins
directory:
myFirstPlugin/
config/
myFirstPluginConfiguration.class.php
lib/
test/
bin/
prove.php
bootstrap/
functional.php
unit.php
fixtures/
project/
functional/
unit/
LICENSE
README
package.xml.tmpl
As you can see, part of what this task does is setup a proper testing
environment for your plugin, including an isolated symfony project to run your
plugin's functional tests through. Once you've created your test scripts, you can easily execute them all by running the prove.php
script before committing your code:
$ php plugins/myFirstPlugin/test/bin/prove.php
Building a robust unit and functional testing suite is a strongly recommended best practice, but if you would rather not bother you can simply include the
--skip-test-dir
option when generating your plugin.
New Task: generate:plugin-module
Often times a plugin will require one or more modules to support its
functionality in the project, such as an administrative backend interface. In
order for your module to be easily customizable for its housing project you
will need to provide a "stub" actions class that can be replicated and
customized in an application's modules
directory.
Previously this would have involved either creating the module directory
structure by hand, or running generate:module
in your application and then
copying, modifying and creating new files in your plugin. This process is now
much more streamlined thanks to the generate:plugin-module
task.
$ ./symfony generate:plugin-module myFirstPlugin myFirstModule
Executing this command will add the following to your plugin's directory structure:
modules/
myFirstModule/
actions/
actions.class.php
lib/
BasemyFirstModuleActions.class.php
templates/
test/
functional/
myFirstModuleActionsTest.php
As you develop this module, write all your action code in the
/lib/BasemyFirstModuleActions.class.php
file. Leaving the
actions.class.php
file empty makes it possible to replicate that file in the
project and not lose or have to duplicate code from the plugin; this will be
taken care of by the symfony autoloader and the magic of OOP inheritance.
This task also creates a functional test script for the new module and updates
the embedded test project's config/settings.yml
to enable the module.
New Task: plugin:package
Anyone who has released a symfony plugin in the past is familiar with the
tedious task of filling out the necessary values in the requisite
package.xml
file. We have added the plugin:package
task in order to speed
up this process.
$ ./symfony plugin:package myFirstPlugin
This task will look for either a package.xml
or package.xml.tmpl
file in
the plugin directory. If neither are found, the task will package the plugin
using a default package.xml
template. In any case, if any field values are
not known the task will take advantage of one of the new symfony 1.2 task
features and ask you for that information.
Once the task knows what it needs to package the plugin, a
myFirstPlugin-0.0.1.tgz
file will be created in the plugin directory. Once
you upload this file to the symfony plugins application, your work will become
immediately available to the entire symfony community.
What's Next?
The sfTaskExtraPlugin
is young, but we have big plans for it. If you have any tasks you'd like to see incorporated, please let us know.
Hi,
Nice plugin to create my own plugin. Thanks
But i have a problem with test because the variable $_SERVER['SYMFONY'] don't exist on my computer. Do you have another solution to load the core ?
Thanks
Bertrand
Wow!!...You guys do not give a chance to breathe...I am actually dreaming of symfony. Nice work!
Would be nice to have a task which creates the model class hierarchy (myModelClass -> PluginmyModelClass -> BaseMyModelClass)
Thanks for this plugin it's a great work and has encouraged me to create a new plugin.
@cinxgler Yes, that's on the roadmap. This plugin is very young right now, but I'm glad you're finding it useful!
Wonderful plugin. I'm already putting it to good use. I especially like the use of the test project in the fixtures.
I'm also getting errors with $_SERVER['SYMFONY']. What would normally be setting that?
@Piers Variables in the $_SERVER array can be set from your UNIX shell. In bash, I run "export SYMFONY=/path/to/symfony/lib". This technique doesn't support Windows, although I would like for it to in the future... any ideas?
If useful, I'm using this to avoid setting the _SERVER['SYMFONY'] variable.
http://www.hashbin.com/tJL
Hello, it's must be helpfull.
BTW, I have two small tasks which might be contributed into this plugin.
One is simple wrapper for installWebContent/uninstallWebContent which simply add/remove(copy/remove for windows) symlinks for all plugins which have web folder. (handy with svn)
Second simply symlink webdir from symfony_data_dir to project webdir.
Thanks.
p.s. I am new to symfony, so, might lost something, let me know :)
Nice post !
Thanks for the hard work and the valuable information for sharing with us.