DRY,
Don’t Repeat Yourself (DRY, also known as Once and Only Once or Single Point of Truth (SPOT)) is a process philosophy aimed at reducing duplication, particularly in computing. The philosophy emphasizes that information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency. DRY is a core principle of Andy Hunt and Dave Thomas’s book The Pragmatic Programmer. [0]
[0] Wikipedia: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself/
Before searching for a way to, apply Phing [1] to T3 extensions I tested it in a small independent project (PHPUnit_CoolUI [2]), that I could configure as I pleased. And it was indeed a pleasure. After having learned and integrated Doxygen [3], Docutils [4] and Phing I was able to process a full new release with one click. Editing, updating the source files, INSTALL, README, TODO, FeatureRequests, ChangeLog, etc. with version and path informations. Including a lot of this informations automatically into the manual and finally packing it all to a tarball for release.
DRY, this self-evident principle is not always that simple to meet and far away from beeing systematically applied within TYPO3. Just the opposit. It’s hard to publish a clean extension, that respects all coding guidelines, because you have to place the same information into different places repeatedly for each release.
Take the changelog as example. There is a ChangeLog file in the extension. The changelog information should be appended to the manual and also pasted into the upload form to TER to be displayed on typo3.org. It’s similar for the TODO. The current version number should ideally be added to all class files, that have been altered and nearly in every involved file and document.
Well, there are solutions. CVS [5] and SVN [6] can automatically update version markers in the sources. API generator tools can apply version informations to the generated API, that is configured in the configuration. Document generators offer markup for automatic insertion of informations like version strings. All this can simplify the maintainance of software, but you still have to manually maintain the configuration files of the different tools to set the current properties.
Another step is needed, to autoupdate the differnt configuration files and to run and controll the generators and tools efficiently. Nothing special, no need to reinvent the wheel. Programming of compiled languages like C or Java can’t be done efficiantly without a tool for this kind of stuff. There are different Makes [7] for C, C++ there is Ant [8] for Java. Certainly you could write simple shell scripts to reach similar targets or use a scripting language like PHP.
PHP doesn’t need to be compiled and the project management automatisms can be coded in PHP themself. Reasons why tools like Ant havn’t been available for PHP early. However, since a few years Phing is availble implementing conceptions of Ant for PHP.
Setting up a development environment with Phing may sound oversized for a little freelancer developing a small TYPO3 extension. In the moment you want to maintain a public open source product over multiple versions, with user and admin documentation, with licences, maybe with a website, such an environment becomes extremly handy. Not to speak of a bigger project team
with multiple persons.
What system do you use?
Should we set up such an environment for extension development for example by enhancement of the extdev extension?
What tools would you recommend to include?
[1] Phing: http://phing.info/docs/guide/current/
[2] PHPUnit_CoolUI: http://cool.sf.net
[3] Doygen: http://www.stack.nl/~dimitri/doxygen/
[4] Docutils: http://docutils.sourceforge.net/
[5] CVS: http://www.nongnu.org/cvs/
[6] SVN: http://subversion.tigris.org/
[7] Make: http://www.gnu.org/software/make/manual/html_node/index.html
[8] Ant: http://ant.apache.org/manual/index.html
