FLOW3 Supports PHP Vendor Namespaces
Published on Jun 29, 2011 12:47:27 p.m. by Robert Lemke
9 comments
Filed under: FLOW3
The result of the last big refactoring before FLOW3 1.0 now made it to our review queue (typo3.org login required): vendor namespaces support. This new feature has two great benefits: first of all we don't need a central package key registry (like the one we have for TYPO3 4.x extensions) and secondly, it allows anyone to seamlessly integrate third-party packages, such as Symfony2 components and Zend Framework components or virtually any other PHP 5.3 based library.
Namespaces in PHP 5.3
One of the key features of PHP 5.3 was the introduction of namespaces. This can be a big enabler when it comes to mixing libraries developed by different projects and companies (aka "vendors"): Each of them uses their own namespace for class naming, thus avoiding name clashes when the components are put together.
Namespaces in a programming language can be compared with the Internet's domain name system – once you own a certain domain, you're completely free with naming your directories and files because the domain name gives you your own namespace to work in.
Before we had namespaces, the TYPO3 project was using its own namespace-like system: extension keys. Once you registered an extension key at typo3.org, you could be sure that it's safe to use a class name like "Tx_MyExtensionKey_Foo" in your code. That works pretty well in our part of the universe but also has a few drawbacks:
- you need to be online for registering a new package key
- other PHP projects don't have a typo3.org extension key
- it's difficult to find suitable extension keys because easy names like "news" can only be owned by one registrant
FLOW3's Implementation
The implementation of vendor namespaces support took some intensive 7 working days. All parts of FLOW3 somehow dealing with packages, package keys or PHP namespace parts had to be adjusted and backed by new tests. The most visible part of all is the new parent namespace of the framework packages. Our de-facto vendor namespace in the past has been "F3" – the namespace of all packages followed the pattern F3\PackageKey\Foo\Bar ... Since FLOW3 is part of the TYPO3 project, the core team decided to choose "TYPO3" as our new vendor namespace. The Object Manager for example is now known under the class name TYPO3\FLOW3\Object\ObjectManager.
Here's a comparison between old and new for namespace related features in FLOW3:
| Before | After | |
|---|---|---|
| Package Key | FLOW3 Fluid MyTwitter |
TYPO3.FLOW3 TYPO3.Fluid Com.Acme.MyTwitter |
| Namespace | F3\FLOW3 F3\Fluid F3\MyTwitter |
TYPO3\FLOW3 TYPO3\Fluid Com\Acme\MyTwitter |
| Packages/… | Framework/FLOW3/ Framework/Fluid/ Application/MyTwitter |
Framework/TYPO3/FLOW3 Framework/TYPO3/Fluid Application/Com/Acme/MyTwitter |
| resource:// | FLOW3/Private/Templates/… MyTwitter/Private/… |
TYPO3.FLOW3/Private/Templates/… Com.Acme.MyTwitter/Private/… |
| YAML |
FLOW3:
security:
enable: y |
TYPO3:
FLOW3:
security:
enable: y |
Those third-party libraries we already used (Doctrine, the YAML parser, ExtJS) will be moved into dedicated packages. Doctrine for example will now be located in the directory Packages/Framework/Doctrine/ and its classes can be loaded without further ado by the FLOW3 class loader.
Updating Existing Code
Such a big change doesn't come without adaption of existing FLOW3 packages. If you're one of those who already created FLOW3-based packages, you'll be happy to know that most of the code adjustments will be done automatically. Along with the new feature, FLOW3 comes with a migration script (located in Packages/Framework/TYPO3/FLOW3/Scripts/) which scans existing packages for necessary changes to PHP code, YAML settings and HTML templates. All references to the FLOW3 framework and its related packages (such as "Fluid" or "Party") will be updated. After the migration your own package will reside in the "MyCompany\[old package key]" namespace (ie. replacing "F3" by "MyCompany") and you will have to do a global search and replace to adjust your package to the vendor namespace you intend to use in the future. As the last step you'll need to manually move your package to the correct directory and flush the caches.
Next Steps
The FLOW3 core team is currently reviewing my patches and we're migrating our existing code base (TYPO3 5.0, the T3CON11 site and plugin and the Blog). We already were quite busy updating the FLOW3 manuals last week and will continue with that for certainly two weeks. Along the way we'll fix bugs we don't want to see in the 1.0 beta 1 and keep focused on finding the shortest, yet reasonable way to the first beta release. As it seems, we won't be able to keep the tentative release date (scheduled for next week) but we don't want to miss it by months either. As soon as all 1.0 features are basically working and the documentation is updated, we'll release FLOW3 1.0 beta 1 – and it would bug me a lot if that wouldn't happen in July ...
Comments
Leave a reply
Robert is TYPO3 Phoenix and FLOW3 founding dev, espresso lover, optimist and proud husband and father.
Recent Posts
- FLOW3 1.1 Beta Releases
- FLOW3 Codesprint and FLOW3 1.1
- Conferences in June 2012
- Results of the Research & Development Meeting
- I'm Fine with Cross-Country
Great to have vendor namespaces, thx!
What about the created database packages, do they also contain the vendor namespaces? This could be useful if i install for example two "News" packages (my own and one wich is just there to share some classes but also contains database tables)?
Yeah great!
But i don't like the "TYPO3\FLOW3" namespace part.
I thougt TYPO3 5 uses the FLOW3 Framework. So FLOW3 is not a part of TYPO3 but TYPO3 is a part (extra package) of FLOW3. that was a wrong decision in my opinion.
So, FLOW3 is a part of the package TYPO3? Or, that is what the namespace example shows :-) I thought that FLOW3 was suppose to be a "stand alone product" and TYPO3 was built on top of it, but FLOW3 still branded as a TYPO3 Association product?
I'm sorry for taking your post in a different direction, but still hope it will be considered :)
Choosing a common vendor namespace which fits FLOW3, Fluid, TYPO3 and all other packages the core team will release, is pretty hard. Because FLOW3 packages will be used standalone but also as part of TYPO3 v5, the best common denominator we could come up is the TYPO3 Project.
After all it's the TYPO3 community / project who made all this possible and even if FLOW3 is a project of its own, it is still funded and coordinated by the TYPO3 community.
I agree that TYPO3\FLOW3\... takes a bit getting used to. But equally would FLOW3\TYPO3\... be odd at first glance for the TYPO3 package's base namespace.
My guess is that we'll soon get used to it and that it doesn't matter so much in the end. And finally let me point out that the namespace is "TYPO3" and not "T3A" – because it's at home in the TYPO3 community and not a product of the TYPO3 Association.
Big up for this feature!
I agree, also don't mix up TYPO3 the product and TYPO3 the "brand".
The FLOW3 package can be used without the TYPO3 package, but it is still a product of the TYPO3 project.
Thanks for the great work! I like the change and totally agree change of the namespace.
Hi Robert,
Thanks for clearing out the thoughts behind the namespace.
It makes a lot more sense with "TYPO3" as first part after reading your comment!
Ok now i agree. thanks for the clarification
At first I wasn't really convinced when this solution was discussed in the mailing list. But after giving it a second thought now, I have to say that this will be the best and cleanest solution for the future.
It's quite a bit to type though but at the end it's just a matter of proper code completion.
The only downside is that you have to have a domain which you want to use for a package if you develop one. But I guess this shouldn't be a big deal nowadays.
Thanks for the great work!