- Andreas Wolf
- Christian Kuhn
- Helmut Hummel
- Thomas Maroschik
- Marc Bastian Heinrichs
- Markus Günther
- Daniel Hürtgen
- Anja Leichsenring
Streamline, bug fixing and zapping the gremlins
This Extbase code sprint served two purposes. The first and foremost is stabilisation of existing features, that means provide, review, improve and merge patches for bug reports we receive through forge. This was mainly the task of Markus, Marc Bastian and Anja supported by the Core Developers present. We successfully handled 30 pending issues during this process.
Compatibility to models of the File Abstraction Layer (FAL)
It was Helmut and Andreas’s task to improve the interaction between FAL and Extbase. Some annoying and blocking bugs were fixed, and improvements were started. As an example there will be different Extbase bootstrap mechanisms for backend and command-line (CLI) context in the future. FAL is for Extbase 'just another one-to-many relation'. Due to this work on FAL some bugs in handling relations in TYPO3 CMS were solved as well, which was a very welcome side-effect.Zapped the string comparison gremlin in Fluid
The code sprint team had some fun integrating 'low hanging feature fruits'. As an example String comparison in the If-ViewHelper has only been possible by using array as container objects and is really considered a gremlin. Christian Kuhn, in his "I do this now!" mood, just backported that feature from Flow Fluid 2.0 to ease and enable constructs like <f:if condition=”object.value = ‘enabled’”>.Streamlined property mapper
In comparison to the aforementioned benefits the streamlined property mapper might count as a smaller success: We can finally enable the rewritten property mapper by default in TYPO3 CMS 6.1. The security concerns, that hindered this until 6.0, have been solved by backporting the accordant white listing from TYPO3 Flow. This change is fully compatible for extensions using Fluid forms and at the same time increases security, as only rendered or explicity allowed properties of objects can be manipulated now.
Vision and view on the Future
The second purpose of this code sprint was discussing and prototyping future features we would like to see implemented in Extbase.Transition to TYPO3 Flow and Doctrine2
Tom is working on Doctrine integration, of which parts will be target to be integrated for TYPO3 CMS 6.1 and also moved towards integrating Flow itself into the TYPO3 CMS bootstrap. When this work is done, the Flow Configuration Management, Composer Support and Doctrine2 will be available. This will take time, and a lot of tasks are still open in this area, especially the construction of a wrapper enabling Extbase to make use of the Doctrine database layer. As one might guess, there’s still plenty of work to be done. Converging TYPO3 CMS and TYPO3 Flow is an important initiative, and with this we see the <link http: typo3.org roadmap berlin-manifesto>Berlin Manifesto become reality.Steps towards a clean configuration layer
Christian worked on his all-time obsession, simplifying Core code and circumventing various pitfalls of complex setups. The main target is to unify the table configuration array (TCA) and to make this entirely available for all rendering contexts. This eases the development process a lot since one does not have to make sure, that all needed parts of the TCA are available and does not need to be determined by additional and complex round-trips. The most important change for having a streamlined TCA is to get rid of the separation into a control and definition block - being located in different files. A functional and non-breaking version was achieved during the sprint, however this still needs further care and expansion.Refactoring the locking mechanism
Daniel as fresh Extbase team member worked on refactoring the locking mechanism of the TYPO3 Core, which could be beneficial for Extbase as well. This way the current strict coded structure can get resolved and extended by additional behaviour to ease integration in distributed processing, such as required for cloud infrastructures and platform-as-a-service (PaaS).Backport Fluid of TYPO3 Flow 1.1
Next point on the list is the fact, that with TYPO3 6.1 we will ship a full backport of Flow Fluid 1.1, containing all improvements made for TYPO3 Fluid. Tymek pushed patches for the backport, which were immediately reviewed by the sprint attendees as well. Yet another step towards transition to TYPO3 Flow.
Improved Quality Assurance
In terms of code quality travis now runs approx. 5.100 Unit tests after every merge (the TYPO3 Flow project runs about 3.500 in comparison). We are down to 6 incomplete tests, all belonging to Fluid. Those tests are the same as in Flow Fluid and will be removed or reimplemented after synchronisation with Flow.
We had as a guest for one evening, Bastian Bringenberg, member of the server team and doing very valuable background work with his dear colleagues. We discussed several strategies to improve the automated testing workflow and how to achieve complete test runs for each change prior to the accordant merge to the upstream repository. Thanks for you visit, Bastian, and thanks for your ideas and engagement. Thanks to all participants and our host <link http: www.rheinschafe.de>Rheinschafe, to make the code sprint possible and for the continued focus on improving TYPO3 CMS. Furthermore we thank our sponsors <link http: www.dkd.de>DKD, <link http: www.netimage.dk>Netimage, Claus Due, Ingo Schmitt and Jari-Hermann Ernst for their support.
Yours,
Anja Leichsenring (on behalf of the Extbase Team)