Second TYPO3 CodeSprint Freiburg in 2012

Categories: Development, Community Created by Steffen Müller
The TYPO3 Extension-/PackageBuilder team met in Freiburg from November 2.-4. 2012 for a three day code sprint. The outcome was big step towards a new user interface, refactored code base to integrate new features and a clear vision for the future.

About the ExtensionBuilder and PackageBuilder

The ExtensionBuilder is a product of the TYPO3 community, which enables developers to create TYPO3 Extbase Extensions using a graphical user interface called the modeller. The modeller allows you to rapidly create Extensions using Domain Driven Design principles. It delivers high quality and ready-to-use source code. It also features the editing of existing Extensions, which is a key feature for agile development approaches. In the current situation the ExtensionBuilder only supports TYPO3 CMS extensions, although more products of the TYPO3 family could benefit from this tool. Since the codebase of the user interface and also the underlying PHP code have reached the end of scalability, the decision was to create a new product called PackageBuilder. One of the goals for the new PackageBuilder is to support multiple target frameworks like TYPO3 CMS, Flow and Neos. Another goal is to introduce a new user interface design, integrated with emberJS and jQuery.

Project team

The CodeSprint attracted two new active project members: ... and Henjo Hoeksma (@henjohoeksma <link https: twitter.com henjohoeksma>twitter.com/henjohoeksma )
changed his status from inactive to active.
The Freiburg Code Sprint Team

Output Strategy

The code sprint started with a discussion about the big picture and the corresponding conceptual and architectural topics. We are aiming for greater extensibility and flexibility to support multiple platforms. We needed to decide on changing the file structure because the current architecture was not flexible enough yet. Although TYPO3 Extbase was derived from TYPO3 Flow, the file structures have diverged in some aspects. How to design and implement the classes handling the output? During this discussion Henjo suggested to introduce strategies. We mainly have two of them in the base package: a TYPO3 CMS strategy and a TYPO3 Flow strategy including Neos. The refactoring we decided on will actually support registering new strategies to this list. Imagine new strategies to be published on the web like Symfony2, yuml.me or ArgoUML for example. The current idea is to support different kind of outputs for the package you're working on, basically expanding the target group of the PackageBuilder a lot. Since the plan for this year is to release an alpha version, we were only refactoring the basic structure. The full feature for registering new strategies will be implemented (and documented) in a later release. For now each strategy can be registered by just adding an entry to TYPO3.PackageBuilder.strategyProvider in Settings.yaml
Rens and Strategy

PHP Parser

The ExtensionBuilder allows to edit existing classes when changing the model. The editing is done using a regular expression based parser. Although it works fine, it is already too complex and lacks of extensibility. So we started to integrate the a PHP parser for creating class objects from pure PHP template classes. The parser was originally written by Nikita Popov and extended by Thomas Maroschik. Nico de Haen finaly embedded it into an API (<link https: github.com nicodh php_parser_api tree flow3_package>github.com/nicodh/php_parser_api/tree/flow3_package).

TYPO3.Ice

TYPO3.Ice is a package offering you an easy way to create an IDE like user interface and is derived from the TYPO3 FormBuilder. We use TYPO3.Ice as the foundation of the Package Builder. Further work on Ice will be done, like making it fully structured like Emberjs, and implementing the server communication. First of all, the TYPO3.Ice package was cleaned up a lot. Thomas Maroschik and Rens Admiraal had a brainstorming session about how to store the actual data in the workspace, how to handle a history and how data handling could support collaborative editing. The outcome was, that CQRS and event sourcing seem to be a promising approach for that. By storing commands in localStorage and syncing them with the server we can simply support versioning, and far easier recognize changed property names in the model for example. The support for this command store will be build into TYPO3.Ice making it available for us in other community packages.

User Interface

The frontend got a rework with help of our new designer Nicki Uhlbach and is now much cleaner and easier to handle. The Modeller now has sophisticated support for storing data in the browser's localStorage which helps us with further implementation of restoring built extensions. Having Nicki on the team is of great value as developers normally ain't that good in user interfaces and designs Hans Christian Reinl already started implementing the design, leading to a much improved user experience. When it comes to handling large domain models, the ExtensionBuilder always had one disadvantage: The lack of overview. Once the domain model exceeded a certain amount of models, it became difficult to maintain: Relations were hard to connect and the panel was generally overloaded with model fields. In order to optimize the user experience, the following features come along with the Package Builder: Zooming: With zooming, we effectivly fix one of the most common problems users were experiencing with the ExtensionBuilder. Users are now able to get a full view on their domain models as well as a detail view. They can experience a whole other level of control about their domain model.

Behaviour Driven Development

We tried to create functional test scenarios for key features of the web interface. It turned out to be more difficult than expected, because the BDD framework Behat/Mink we used was not stable enough for our use cases. However the goal is still to create test scenarios, but a different framework needs to be evaluated. Cucumber could be a candidate.

Integrating the PackageBuilder into TYPO3 CMS

The new PackageBuilder is built as a TYPO3 Flow package. To backport it to TYPO3 CMS, a new TYPO3 Flow Package has been started that creates a standalone version of the PackageBuilder. This will allow to ship it within a classic extension and integrate it into the TYPO3 CMS Backend.

Preview

If you want to have a look at the actual state, use the PackageBuilder Distribution-Package github.com/nicodh/BaseDistribution_TYPO3.PackageBuilder (including Flow and all dependant packages). A short howto can be found in the PackageBuilder Wiki: forge.typo3.org/projects/package-packagebuilder/wiki

Summary

The PackageBuilder will be more feature packed, more advanced and an even greater joy to use then envisioned before. Great stuff happen when great minds join forces. This CodeSprint was some nice community work!

Sponsors

Without sponsoring, the sprint could not happen. We received great support from a number of TYPO3 agencies, including travel costs, workspace, accomodation, drinks and food. We like to say thank you to: