Any piece of software can only be as good as its foundations. To rise as high as we need it to, we decided eZ Publish needed new ones. Today, we will tell you how these are architectured, and give you a glimpse of their possibilities.
4. Current architecture
• RDBMS dependent, and strongly bound to the database structure
• PHP 4 ages legacy :
o Weak OOP concepts (no interfaces, no abstract, no excepGons, no magic, no dependency
injecGon, everything is public)
o Global variables usage (for singletons on in-‐memory cache)
o (And also some dirty workarounds)
• Low level API
o Hard to catch
o SomeGmes dangerous to manipulate directly (for data integrity)
o No real API doc, hence no developer doc
• Hardly testable
samedi 15 octobre 11
5. Consequences
• Evolu'ons are very 'me-‐consuming
• Maintaining backward compa'bility is very complex
• No possible support for NoSQL
• Impossible to perform RDBMS specific op'miza'ons
(na've func'ons and procedures, like in Oracle, or even
latest MySQL)
• Bad API usage (and "Black Magic")
samedi 15 octobre 11
8. New architecture overview
• Kicked off with Domain Driven Design methodologies
• Storage system agnos'c
• Extensible
• Secure
• Easy to use
• Modern (PHP 5.3, namespaces, design paUerns...)
samedi 15 octobre 11
10. Do you speak eZ Publish ?
The refined domain defini'on comes up with new terms:
Content Object Content
Node Loca/on
Content Object A1ribute Field
Content Class Content Type
Content Class A1ribute Field Defini/on
Datatype Field Type
Easier to understand for newcomers and non-‐technical people (Domain design approach)
samedi 15 octobre 11
11. Public API
• Public API is the ONLY API any developer should use directly
• Any developer = eZ Engineers included (kernel modules)
• Should be sexy and very easy to use
• High level, so that the developer doesn't care about the
backend
• It interacts seamlessly with the business layer in the backend
samedi 15 octobre 11
12. Business layer
• This is the layer where most of the logic is implemented
• It is completely storage agnos/c, as it uses the content
persistence API.
• It uses the Content Repository to manipulate the CMS data.
• It doesn't delegate logic to the content persistence API.
samedi 15 octobre 11
13. Persistence layer
• Starts as a set of interfaces.
• These interfaces are implemented by every content
repositories (aka Storage Engines).
• Ensures full abstrac/on between the business layer and the
storage mechanisms.
• Contains as liUle logic as possible. It cares about data, only
data. Logic is in the business layer.
samedi 15 octobre 11
14. Storage engines
• Storage engines implement the Content Persistence
Interfaces
• Each storage engine corresponds to a type of data storage
o Classic RDBMS (MySQL, PostgreSQL...)
o Document oriented storage (NoSQL)
o ...
• Internals are completely hidden, and can use anything: ORM,
ezcDatabase, REST, SOAP...
samedi 15 octobre 11
15. Do you speak eZ Publish ?
New, fancy terms
• Repository: Centralized, virtual storage system. Implemented
by storage. Also used for binary files.
• Domain Object (aka DO): High level PHP object exposed in
public API: Content, Loca'on, Field, etc.
• Service: Interac'on components from the Business Layer:
Content, Loca'on, etc.
samedi 15 octobre 11
16. Legacy Storage Engine
• eZ Publish 4 database Persistence Layer implementa'on
• Implemented from scratch. Shiny !
• Uses the Zeta Components (ezcDatabase + ezcQuery)
• Tested to be two-‐ways compa/ble with eZ Publish 4:
➡ content created from ezp4 is available in the API
➡ content created from the API is available in ezp4
• No migra/on required !
samedi 15 octobre 11
17. Code !
That’s why we’re here, right ?
samedi 15 octobre 11
19. Create content
<?php
use ezpBaseServiceContainer,
ezpBaseConfiguration,
ezpContentFieldTypeUrl;
// Get the repository, and configure the user to use
$sc = new ServiceContainer( Configuration::getInstance( 'service' )->getAll() );
$repository = $sc->getRepository();
$contentService = $repository->getContentService();
$repository->setUser( $repository->getUserService()->load( 14 ) );
// Build a new folder
// $folder will be a DO, ezpContent
$folder = $contentService->init( 'folder', 'eng-GB' );
$folder->fields['name'] = 'News';
$folder->fields['description'] = '<p>My <strong>ubber cool</strong> description !</p>';
$folder->fields['link'] = new UrlValue( 'http://ez.no', 'eZ Systems' );
$folder->addParent( $repository->getLocationService()->load( 2 ) );
$folder = $contentService->create( $folder );
$contentService->publish( $folder->versions[1] );
samedi 15 octobre 11
20. Load content
<?php
use ezpBaseServiceContainer,
ezpBaseConfiguration;
$sc = new ServiceContainer( Configuration::getInstance( 'service' )->getAll() );
$repository = $sc->getRepository();
$contentService = $repository->getContentService();
try
{
$content = $contentService->load( 60 );
}
catch ( ezpBaseExceptionNotFound $e )
{
echo "Content could not be found in the repository !n";
exit;
}
// Loop against fields.
// $identifier is the attribute identifier
// $value is the corresponding value object
echo "Content '{$content}' has following fields:n";
foreach ( $content->fields as $identifier => $value )
{
echo "Field '{$identifier}': {$value}n"; // Using $value __toString()
}
samedi 15 octobre 11
22. Field types
• Now spliUed in (at least) 2 objects:
• Type
• Value
• Dedicated PHP namespace
• Interfaces to determine which features the field type
implement (Searchable, Collectable...)
• Converters for Legacy storage engine
samedi 15 octobre 11
23. Roadmap
• Full language/transla'on support
• Finish migra'ng datatypes
• HTTP layer + modules
• REST API implementa'on based on the new API
• Op'mized storage engines
samedi 15 octobre 11
24. Now it’s your turn !
•Get it : http://github.com/ezsystems/ezp-next
•Blame it : http://issues.ez.no/ezpublish (ezpnext component)
•Discuss it : http://share.ez.no/forums/new-php-api
•Own it : Make a GitHub pull request !
Soon to come: wiki based cookbook, blog posts.
samedi 15 octobre 11