5. Future ‣ Can my data produced today
Proof be migrated elsewhere and
Data reused in the future?
BUSY NOGGIN
DIGITAL
6. Future ‣ Will my code continue to
Proof work in the future?
Code ‣ Is my code portable to other
platforms?
‣ Is my code maintainable by
other developers?
BUSY NOGGIN
DIGITAL
7. Future ‣ Is the platform maintained?
Proof ‣ Is backwards compatibility
Platform valued?
‣ Is future-proof code
encouraged?
‣ Does it give me room to
grow?
BUSY NOGGIN
DIGITAL
8. Future ‣ Is the way I think about
Proof development transferrable
Dev from one project to the next?
‣ Am I the only one who can
work on this project until the
end of time?
BUSY NOGGIN
DIGITAL
9. Busy ‣ Invest up front, reap benefits
Noggin later.
Approach ‣ A swiss army knife is the best
tool for the job.
‣ We focus on future-proof
knowledge more than future-
proof code.
BUSY NOGGIN
DIGITAL
10. Does TYPO3 provide a future
proof development platform?
BUSY NOGGIN
DIGITAL
12. “Future releases of v4 will see its features
converge with those in TYPO3 v5”
BUSY NOGGIN
DIGITAL
13. “TYPO3 v5 will introduce many new
concepts and ideas. Learning never
stops and we'll help with adequate
resources to ensure a smooth transition”
BUSY NOGGIN
DIGITAL
15. Extbase ‣ Who uses Extbase already?
‣ How Busy Noggin uses
Extbase
- 12K product app with
nightly inventory imports
before Extbase had reached
beta
BUSY NOGGIN
DIGITAL
18. Extbase ‣ Who uses Extbase already?
‣ How Busy Noggin uses
Extbase
- 12K product app with
nightly ERP imports before
Extbase had reached beta
- and we’ve used Extbase for
all extension development
since then
BUSY NOGGIN
DIGITAL
19. Extbase ‣ Features
- Domain Driven Design
- Dependency Injection
- Persistence Layer
- Signals and Slots
- Property Mapper
- Fluid Templating
BUSY NOGGIN
DIGITAL
21. Extbase ‣ How is it an improvement
over pibase?
- Persistence Layer
- No boilerplate code for
templates
- More opinionated
framework makes it easier
to start
BUSY NOGGIN
DIGITAL
22. Extbase ‣ What is the sweet spot?
- CRUD apps within a larger
CMS project
‣ Where does it struggle?
- Large datasets
- Dynamic, high performance
applications
BUSY NOGGIN
DIGITAL
43. Neos ‣ Who uses Neos already?
‣ How Busy Noggin uses Neos
- Light content management
alongside a Flow application
- Don’t reinvent the CMS
wheel for Flow
BUSY NOGGIN
DIGITAL
44. Neos ‣ Features
- Domain Driven Design
- Persistence Layer
- Signals and Slots
- Property Mapper
- Fluid Templating
- Aspect Oriented Programming
BUSY NOGGIN
- CMS
DIGITAL
45. Neos ‣ Set of packages on top of
Flow
- Content Elements,
TypoScript, Image
Processing, Content
Repository, etc
‣ Neos plugins are Flow
packages with a little extra
setup code
BUSY NOGGIN
DIGITAL
54. Does TYPO3 provide a future
proof development platform?
BUSY NOGGIN
DIGITAL
55. “Future releases of v4 TYPO3 CMS will
see its features converge with those in
TYPO3 v5 Neos”
BUSY NOGGIN
DIGITAL
56. “TYPO3 v5 Neos will introduce many
new concepts and ideas. Learning never
stops and we'll help with adequate
Text
resources to ensure a smooth transition”
BUSY NOGGIN
DIGITAL
57. ‣ The concepts of TYPO3
Extbase, Flow, and Neos are
very similar
‣ Code may not be directly
portable up the chain, but
there is a high degree of
overlap
BUSY NOGGIN
DIGITAL
58. ‣ Architecture encourages
stable, maintainable code
‣ TYPO3 Extbase, Flow and
Neos cover a wide range of
use cases
BUSY NOGGIN
DIGITAL
59. Am I practicing future proof
development?
BUSY NOGGIN
DIGITAL
If the title of this talk is “Future Proof Development” the first question to answer is what exactly we mean by future proof. There are several ways to look at it.\n
As long as data formats are structured, its possible to migrate data but that’s not what we’re going to talk about today. Within the TYPO3 family, we can envision code to migrate pages and basic content from one product to another.\n
When we talk about future proof code, we’re talking about the actual classes and methods you create.\nWill it work when a new software version comes out? In the TYPO3 context, does the code you wrote for 4.5 work in 4.7 and 6?\nCan it be moved to a new system without having to rewrite from scratch?\nIs it written in a way that others can understand and maintain it?\n\nMany of these questions are being addressed by the PHP Standards Working Group, PHP The Right Way, and package management systems like PEAR and Composer\n\n
Moving up a level, we can talk about a future proof platform. This is the product (TYPO3 CMS, Wordpress, Drupal) or family of products (TYPO3) that you develop on. Rather than specific code, we’re more concerned with high level capabilities and where the platform excels.\n\nA future proof platform is not a dead end. The attributes of future proof code from the previous slide are encouraged by the platform. One example of this is TYPO3‘s deprecation policy; you know that code written today will continue to work for several versions in the future.\n\nA future proof platform is actively developed and grows with your business so that an up front investment continues to pay off. It meets your needs today, but meets your needs next year as well (as best as you can determine those needs)\n
The top level and most abstract level is future proof development. This may cut across multiple platforms, and is really about the way you and your company approach development.\n\nIs the way you think about development transferrable from one project to another or are you starting from scratch each time you begin a new project?\n\nIf you get run over by a bus, can someone else pick up the project and successfully complete it?\n
We are not scared off by a learning curve. When we choose a product, we want to build up a base and use it for many projects in the future.\n\nA product with a broad feature set and many use cases can be adapted for many projects. Build that base, and then use it. Don’t pick a narrow product and relearn each time.\n\nFuture proof code is a good thing, but we try to primarily focus on having a consistent way to work and think about projects. We move from one project to another more frequently than we move a codebase from one product to another to another. This means we value a common mindset among multiple products.\n\nPractically, the way this plays out for us is the TYPO3 ecosystem. Historically, we’ve done all of our site builds in TYPO3 CMS, the “go anywhere do anything” CMS. We use Extbase as our development framework in TYPO3 and have recently added Flow and Neos into the mix.\n\nAt the same time we are practical in our choices. TYPO3 is not the best option for e-commerce work, especially in the US market, so we’ve landed on Magento.\n\nWe think the TYPO3 family of products provides a good platform for future proof development. If you want to take my word for it, we can go grab lunch now. Otherwise, I’ll show why.\n
Since we are here at a TYPO3 conference, the obvious question is how these statements about future-proof pertain to the TYPO3 family of products.\n
Shortly after T3CON08 in Berlin, the TYPO3 Core Team met for a week of discussing strategy, coding, and other activities. One result of the week was a statement about the future of TYPO3 development.\n
\n
\n
Another output of the core team meeting in Berlin, was the beginning of a new extension framework called Extbase. Extbase is a backport of key concepts from Flow.\n
Last year couple years of T3CON felt like “why you should use Extbase” now it seems to be more of a given\nExtbase (and the related template engine Fluid) are a modern development framework within the TYPO3 CMS.\nPreviously, an API named pibase provided common methods but no real opinionated way for developing within TYPO3\n\n
\n
\n
\n
Domain Driven Design - a way of modeling real world objects within your extensions\nDependency Injection - loose coupling of related components. for example, choosing a logging method at runtime rather than hardcoding it\nPersistence Layer - Handles retrieving and saving domain models\nSignals and Slots - Event messaging to determine when an action has occurred and trigger other listening code to run\nProperty Mapper - Transforms URL parameters into full-blown objects\nFluid Templating - Object-aware templating engine, with support for layouts, partials, and view helpers\n
\n
The persistence layer is a huge help by removing the need for hand written SQL queries and worries about SQL injection, etc. Custom SQL queries can still be written when you have a complex query or need to squeeze out extra performance\n\nWhen writing the old style pibase extensions, one of the biggest annoyances was the amount of dumb code needed for loading templates, setting up markers, and looping over subpart. Extbase and Fluid remove all that.\n\npibase was a thin API that did not really provide direction to the developer. Extbase establishes much stronger conventions about how extensions should be structured.\n
CRUD = create, read, update, delete. in particular, create and update forms are far simpler in extbase\n\nI previously mentioned our 12,000 product entry into the Extbase world. Performance was definitely a challenge here due to the large dataset with many relations. In our case, we solved most of the problems with heaving caching but this is not always an option.\n
Quick tour of the way an Extbase extension is structured and show the todos app\n
\n
\n
\n
\n
\n
Our next product to look at is TYPO3 Flow. As TYPO3 v5 (ie. Neos) was developed, an application framework named Flow was extracted from the new CMS.\n
Since Flow is an application framework, its use cases are different than those of TYPO3 CMS and Extbase. It sits in a place more similar to Symfony, CakePHP, and Ruby on Rails. Flow does not provide a CMS, but if you wanted to write your own CMS you could build it on top of Flow.\n\nBusy Noggin currently has several projects underway using Flow. The first is an iPhone and Android app. It relies on CouchDB for its primary data storage, with Flow sitting between the app and CouchDB.\n\nWe are also developing an online store for configuring and ordering industrial components and tracking their assembly through the factory.\n
\n
The features you see here should look very similar to what we’ve seen in Extbase.\n\nOne important and powerful addition is Aspect Oriented Programming. This provides a powerful way to make your own code run before, after, or around any existing method with no code required from the original developer.\n
Quick tour of directory structure and differences from Extbase\n
\n
\n
\n
\n
\n
\n
\n
It sounds strange, but the use case for Neos right now is in lighter content management sites. This could be two things:\n1) Sites that would normally be built in TYPO3 CMS, but don’t really require much beyond built in content elements\n2) Projects that are primarily custom applications, but have some smaller CMS needs\n\nBoth of our projects I mentioned previously (the mobile app and the industrial components) fit into #2. For the mobile app, I was worried that Neos was not mature enough for use and added my own really lightweight way of handling pages and content that involved me editing HTML templates. Let’s just say that I’m porting the site over to Neos now.\n
Again, this feature list should look very familiar. We have all the features of Extbase and Flow, with a CMS added now. There’s a reason for this commonality....\n
Neos is nothing more than a set of packages that are available for Flow. These packages provide the functionality that you are already familiar with from TYPO3 CMS ... content elements, TypoScript, image resizing, etc.\n\nNeos plugins are nothing more than Flow packages with a little bit of setup code to make them available as content elements. We’ll see what that looks like in a second\n
Quick tour of directory structure and differences from FLOW3\n
\n
\n
\n
\n
\n
\n
Now that we’ve looked at 3 products that TYPO3 offers, we can come back to some of our original questions. First, does TYPO3 provide a future proof development platform?\n\nAnother way of answering this question is to look back at the Berlin Manifesto 4 years later and see where we are today\n
\n
\n
There are a multitude of ways that we have seen features converge between TYPO3 CMS and Neos. Extbase was created as a backport of Flow into the TYPO3 CMS environment and both our feature list and example extension show us how much commonality there is. Fluid as a templating engine is available for both TYPO3 CMS and NewCMS. We haven’t had time to touch on them today, but important features such as the caching framework and xliff translations have been backported from Neos to TYPO3 as well.\n\nThere are certainly code changes needed, and our example plugins are admittedly as simple as they come. As extensions get more complex there will be deeper connections into the underlying CMS. However, we can see that the way plugins are developed is very similar between Extbase, Flow, and NewCMS.\n
Even in the best framework, someone can write spaghetti code if they really try but Flow provides many features that encourage clean, loosely coupled code. It provides enough strong conventions that another developer can quickly jump in and understand where to find things and how it works.\n\nExtbase today covers the content-driven website build that has the need for custom development alongside it. Flow handles the pure web application, and NewCMS adds light content management (and becoming more full featured each day). This positions a developer to be handle any scope of project that comes his way.\n\n\n
Am I writing maintainable, portable code?\nHave I chosen products that are well-maintained, serve my needs today, and serve my needs in future?\nAre the products that I use complementary to one another, so that shifting from one project to another is not starting from scratch?\n\n