Phing was designed to be flexible and easily extensible. Phing's existing core and optional tasks do provide a great deal of flexibility in processing files, performing database actions, and even getting user feedback during a build process. In some cases, however, the existing tasks just won't suffice and because of Phing's open, modular architecture adding exactly the functionality you need is often quite trivial.
In this chapter we'll look primarily at how to create your own tasks, since that is probably the most useful way to extend Phing. We'll also give some more information about Phing's design and inner workings.
There are three main areas where Phing can be extended: Tasks, Types, Mappers. The following sections discuss these options.
Tasks are pieces of codes that perform an atomic action like installing a file. Therefore a special worker class hast to be created and stored in a specific location, that actually implements the job. The worker is just the interface to Phing that must fulfill some requirements discussed later in this chapter, however it can - but not necessarily must - use other classes, workers and libraries that aid performing the operations needed.
Extending types is a rare need; nevertheless, you can do it. A possible type you
might implement is urlset, for example.
You may end up needing a new type for a task you write; for example, if you were
writing the XSLTTask you might discover that you needed a special type for
XSLTParams (even though in that case you could probably use the generic name/value
Parameter type). In cases where the type is really only for a single task, you may
want to just define the type class in the same file as the Task class, rather than
creating an official stand-alone Type.
Creating new mappers is also a rare need, since most everything can be handled by the Appendix F, Core mappers. The Mapper framework does provide a simple way for defining your own mappers to use instead, however, and mappers implement a very simple interface.