2. From simple presentation
and content management
to digital business
Focus on organization’s core-
business and simplify
complexity:
cloud-enablement
Market-driven Innovation
3. The 5 pillars of
Innovation @
eZ eZ
eZ R&D
Community
Community
eZ R&D
Partner conferences
Product Innovation Board
eZ Market
4. AGENDA
• About: eZ & Speaker • Re architecture: Concepts
• Re architecture: Why? • Tobias Schlitt on several
central pieces of the
• Re architecture: Prior work architecture & testing
methodology
• Re architecture: How?
• Re architecture: Next steps
• Re architecture: Mistakes
• ..
5. ABOUT EZ SYSTEMS
• Started in 1999 in Norway
• Employ[ed] several PHP internals/community members
• Locally present in Germany, Norway, UK, France, US,
Italy, Spain, Finland, Japan, China
• Acquired odoscope & yoochoose last year
• 120ish employees and growing
6. ABOUT EZ PUBLISH
• Open source CMS written in PHP
• Focus on:
• Generalization
• Highly extensible
• Lotsof contributed extensions from community &
partners
7. ABOUT SPEAKER
• https://twitter.com/#!/andrerom
• 7 years working with eZ Publish, the community &
PHP
• Before that: Misc html / Js / .Net / web consulting,
Economics studies, dj’ing, military, alpine racing, basket ball
, football, ice hockey, tennis
, *cough* boy scout
8. WHY?
<del>A picture</ * NOTE: you have to provide the following attributes:
* contentobject_id
* contentobject_attribute_id
del><ins>Code</ins> is *
* @param array $row
* @return object
worth a thousand */
static function create( $row = array() )
words!
{
if ( !isset( $row['contentobject_id'] ) )
eZDebug::writeError( 'Missing 'contentobject_id' parameter!', __METHOD__ );
9. WHY2?
• Align the solution closer with target market
• Fully take advantage of PHP 5[.3] features
• Adapt emerging technologies
• Reduce maintenance overhead & simplify use..
• Sync up with the rest of the PHP ecosystem
10. PRIOR WORK
• 2005/6: eZ Components
• 2007: Prototype & planning of refactoring
• 2009: Planning of larger refactoring to support NoSQL
• 2010/1: Start on current eZ Publish 5 efforts
11. TIMELINE
• January 2011: New technical PM starting
• February: Meetings to get a common ground on the architecture
• March: UML provided
• April-Mai: Engineering rejecting the UML and starting on own interpretation of architecture
• June-September: Implementation
• November: Decision to reboot the process
• December - January 2012: Re design
13. HOW: RE ARCHITECTURE
• Adapt
Separation of concern, Domain driven design and
HMVC:
• Dependency/Service injection container
• M: Repository & Services with Model Factories
• C: “Thin” Controllers
• H: Clean (V)views
14. CONCEPT: STRICT “DIC”
• Insteadof container awareness: Closures for lazy d. loading!
Example: Your Router takes a list of Route’s as arguments,
these routes has a dependency on a controller (one pr route)
• Solution: Makethe Route’s only accept is_callable() values for
$controller, making it possible to use: closures, static call or
array( $controller, ‘run’ ) as argument.
• Lazy
loaded (%) closure example with a defined callback:
[ContentLoctionItemRoute]
arguments[uri]=content/location
arguments[controller]=%ContentLocationController::run
[background image curtsy of public-domain-image.com]\n
Original community speaker notes (skipped for time during presentation): \nThe grand narrative of our innovation strategy is simply that of our wider company development strategy: market-driven, leading organizations must adapt to the constantly changing environment and our role is to empower them to create their own, and their communities&#x2019; online services experience.\n \nAn online presence & the display of web content has evolved from simple screen-based presentations and the management of content, towards a set of more systematic and integrated digital business processes. The environment has evolved from generally performing analogue processes with digital technology, to an era of true digitization.\n\nIn most cases management of digital services can now be outsourced which benefits an increased focus on the organization&#x2019;s core-business. Further, cloud-based platform offerings add simplicity, cost-control, and highly manageable complexity. By &#x201C;platform&#x201D; eZ means a closed-loop management capability from content gathering, to systematic optimization of any digital presence and business.\n
Original community speaker notes (skipped for time during presentation):Innovation at eZ lays on 5 pillars. The Community is by nature a strong influencer and important contributor, tightly collaborating with our R&D and Engineering team. Our professional community is one bridge to the market, as is our partner network, which, through regular meetings and conferences, as well as through participation in eZ&#x2019;s Product Innovation Board, brings valuable insight and vision to eZ&#x2019;s Platform. eZ Market, extensions market place, completes the picture.\n\nHere is how we translate this into technology(then continue over to the heart of the presentation).\n
\n
- eZ has had the pleasure of employing PHP people like Derick Rethans, Sebastian Bergmann, Kore Nordmann, Tobias Schlitt, and Patrick Allaert (Last 3 currently working with eZ)\n- Originally pure PHP shop, but now with a diverse engineering team in Cologne after acquisition of osc and ych with competence in C++, .NET and JAVA.\n
- Generalization: makes eZ Publish a fitting solution in a lot of verticals (markets)\n- ext: To avoid need for hacking the solution and hence make it hard to upgrade\n\nFact: eZ Publish was for many years used as an OOP example for software engineering students because of it&#x2019;s extensive use of OOP which was not normal in PHP.\n\n
\n
[Technically]\ntop: Errors don&#x2019;t throw, they give errors often ignored which causes often big [performance|consistency] problems later for implementers, or in worst case the customer.\nleft: Business, persistence and db layer is one and the same causing lots of duplicated code and 0 possibility of NoSQL migration\nbottom: This is considered a &#x201C;clean template&#x201D; in eZ Publish terms, but templates have much more business logic then they should, this leads to issues long term, much more template code to maintain, is difficult to test and impossible to get html knowledgeable designers/hackers to help out on.\n
[Business/Market]\n- As eZ is and has for some year been focusing on the Enterprise market, re factor the product to better serve this market today and in the future\n- Use PHP 5 and 5.3 features from day one, also being able to removing features that can now be handled by PHP or other parts of the stack\n- Start to use patterns and technologies that have been getting foothold in PHP over the last 3+ years\n- Much higher focus on testing up front in form of Unit tests, integration tests and function testing, + layered architecture with separation of concern; reducing code duplication dramatically\n- Adoption of some PSR standards, use of composer, use of Symfony, ...\n
Most notable prior work on refactoring eZ Publish:\n- 2005/6: eZ Components was a rewrite of libraries in eZ Publish on PHP 5.0, intention was to rewrite/refactor eZ Publish on top of these in 2006/7\n- 2007: eZ Publish 4.0 was planned to have bigger changes then it got, but market demand for a PHP 5 version of eZ Publish was to strong so plans changed to release PHP 5 version early\n- 2008: Plans to gradually replace parts of eZ Publish with eZ Components. Archive, SystemInformation, Feed, Mail, SignalSlot and WebDav introduced over the following years\n- 2009: First plans for large refactoring to be able to take advantage of NoSQL databases\n- 2010/1: Start on working on what we currently refer to as eZ Publish 5 \n\n
Zoom in on 2011- Present: How the projects started, surrounding project roles and the different backgrounds of the first 3 involved, goals and timelines.\n- Lack of specifications, or the fact that what was created was not followed by engineers.\n- TPM was not defined as architect, and Engineers where told they where free to take own direction and TPM was only there to help.\n- In the original implementation we relayed a lot on magic because we where first and foremost focusing on making the api as easy to use as possible, hence $content->location[0]->parent->content->section->name would work, but it lead to high levels of complexity and need for things like proxy classes for almost all classes and impossible to use things like var_[dump|export] in php and also lots of circular references. Now: Pure value objects with no knowledge of Repository, more verbose but also much more explicit API, hence making it for instance very obvious when something will trigger database access and not.\n- Take out: Defining your roles in your team, especially who is the Architect and make everyone agree on / believe in the high and mid level view of the architecture. This is especially important when having team members in countries with a culture where employees are used to having a say in decisions\n\n
[High level]\nPublic API that is fully documented, and related to earlier remark on giving errors, gives you exceptions early if you do something wrong, handles permissions for you and deals with sql dialects deep down in the storage engine (PDO)\nGreen arrow shows the currently aimed migration / integrations between &#x201C;legacy kernel&#x201D; and new architecture.\n
- DIC: Handles your dependencies so objects don&#x2019;t have to know anything but interfaces, this leads to lot of less init code (factory calls, singeltons and other things that makes testing harder).- Model: Public API\n- Controllers: Given API deals with SQL abstractions, BL, and permissions, far less works needs to be done in controllers, hence &#x201C;thin&#x201D;.\n- Hierarchical + Views: By adapting hierarchical structure, far less logic needs to be in templates. Makes it easier to unit test your site, and for designers to dare working on your templates.\n - As we have decided to use Symfony Framework for our H + V layers, the proper term is actually request / response, but effect is the same in regards to getting BL out of views.\n
- d.: Dependency\n- Reason why you some time want to lazy load dependencies is most obvious in cases like above (controllers), as they can have a range of dependencies of their own and hence end up loading all services in the systems. Another would be field types in eZ Publish, &#x201C;Content[Type]Service&#x201D; needs to know about these, but loading them all with all their potential dependencies would be overkill.\n
\n
Public API: more field types & permissions, and additional API&#x2019;s (url alias + object state + ..)\nREST API v2: Hateoas REST interface on top of Public API as shown by Tobias\nEditorial interface: Concept work, wire framing, early design work and prototyping.\nSymfony: As frameworks comes and goes, and new breaking versions will always appear when enough new features in the PHP language warrants it, so we will create our own interfaces that cover the most common use cases to extension/plugin writers for future proofing. On top of using Symfony2 we are currently evaluating using some Symfony CMF parts as well.\n\n \n
NoSQL: We plan to do a prototype of a NoSQL implementation of our persistence API in the late summer/ early fall, to make sure our Public API / Persistence SPI interfaces actually works on it.\n
- Sum outtakes: Define your team roles, embrace SOC DDD and other &#x201C;Java patterns&#x201D;, avoid magic (especially if it breaks SOC), this means keeping your dependencies highly de coupled, which again means use of interfaces and absolutely no use of globals including singletons; look into how [D|S] Injection containers work and you&#x2019;ll see the light ;)\n
- As mentioned in the intro, this is a great possibility to work in a diverse team with knowledge from highly scalable cloud infrastructure in java to optimized c++ and algorithms.\n
- git repo includes simple steps for how to checkout and setup the project to run on inmemory implementation, this is still in very active development but expect stabilization by the end of the summer and move to /ezpublish repo.\n
