TYPO3 Congres 2012 - Test-Driven Development binnen TYPO3 Flow en Neos
A Content Repository for TYPO3 5.0
-
Upload
karsten-dambekalns -
Category
Technology
-
view
2.082 -
download
0
Transcript of A Content Repository for TYPO3 5.0
Inspiring people toshare
Special guest: David NueschelerResponsible for the technology strategy and ongoing product development at Day. He joined Day in 1994
Specification lead on JSR 170 and JSR 283.
Also a committer on the Apache Jackrabbit Project and a member of the Apache Software Foundation
He will now tell us more about JCR
Inspiring people toshare
Why a CR for TYPO3?Flexible and extensible data structure
Object based storage and retrieval
Combines advantages of navigational and relational databases
Security can be enforced on a higher level
Cleaner and easier to use for the developer
Inspiring people toshare
More reasons for a CRData source abstraction instead of database abstraction
Data can be stored in different ways, a database is only one of them
Due to the higher level of abstraction, database specific functions and specialties like transactions, stored procedures, partitioning ... can be used on the CR implementation level
Depending on the CR implementation the speed gain for read access to the content tree can be immense
Inspiring people toshare
The Jackrabbit “shortcut”As there exists no PHP-based CR implementation, we looked for alternatives
Jackrabbit is the JSR 170 reference implementation, providing all required and optional features of the specification
Using it from PHP is possible with the PHP-Java-Bridge
Provides a way to write and test PHP-based unit tests that are needed for implementing a pure PHP-based CR
are we crazy?
Inspiring people toshare
A native PHP Content RepositoryTYPO3 5.0 will still run completely without Java - by accessing the PHP-based TYPO3 CR, based on the APIs defined in JSR 170 and JSR 283
The goal: A flexible and powerful content repository for TYPO3 written in PHP
We are not crazy
It is not impossible
Maybe not all of the standard will be implemented – but don’t tell anyone...
Inspiring people toshare
Current statusphpCR: The JSR-170 API exists as PHP interfaces, thanks to Travis Swicegood
The Jackrabbit bridge has proven to be a working setup, although it does not handle the full API yet - maybe it never will
We have a large set of unit tests available for the phpCRJackrabbit package
A first batch of those tests has been generalized to be usable for any implementation of the phpCR interfaces
Inspiring people toshare
Missing thingsA domain model for the CMS part of the project
A way for defining node types based on that model
Inspiring people toshare
Defining the CMS domain modelWe need to focus on the pure domain of the CMS
A first step is to find the common set of objects that form the domain of content management
So, let’s see...
Inspiring people toshare
Defining the CMS domain model
Page Content Element
Page Tree
SitemapPlugin
Backend Module
System Folder
Template Record
Category
Content ElementWorkspace
Inspiring people toshare
A possible hierarchy of thingsAssignment: try to come up with a hierarchy of objects that represent the content we currently have - and trim where possible
You have 10 minutes...
Inspiring people toshare
Node typesTo make good use of a CR, one needs to provide useful node types
A node type specifies
allowed and/or required sub nodes to a node
allowed and/or required properties of a node
supertypes of a node, i.e. inheritance
Inspiring people toshare
The node types of magnolia
<nt:hierarchyNode><mix:versionable>mgnl:metaData
<nt:hierarchyNode>mgnl:content
<nt:hierarchyNode>mgnl:contentNode
<nt:resource>mgnl:resource
<nt:base>*
<mgnl:content>mgnl:group
<mgnl:content>mgnl:role
<mgnl:content>mgnl:user
<nt:hierarchyNode>mgnl:reserve
All nodes can have arbitrary properties...
Inspiring people toshare
Our node types?The node types should (partly) reflect the domain model
Specifically the parts of the domain model, that need to be persisted
Coming up with a reasonable system of node types is not trivial
We need to further work on the domain model, before steps make sense...
Inspiring people toshare
CR configuration from codeCurrently MySQL tables are created when installing an extension
The definition is a plain SQL file
Further data comes from $TCA as defined in ext_tables.php and/or tca.php
Automation needs to stay around, of course
We need to create node types instead of tables and fields
Inspiring people toshare
CR configuration from codeGoals
Get rid of multiple places for defining things
Make it as transparent as possible
Create node types based on PHP objects
Use reflection to gather information about the objects
Create node type definition accordingly
What objects need a corresponding node type?
Inspiring people toshare
Changes to existing node typesChanging and removing a node type is possible
But what about nodes type being in use?
Jackrabbit currently rejects nontrivial changes
We will probably only change node types on explicit request
Changing a node type may fail if the result would be inconsistent repository content
Existing data needs to be removed before a node type can be removed
Inspiring people toshare
CR configuration from codeJSR 170 had no defined API for registering node types
JSR 283 will have it, and we will use that by
adding it to the phpCR interfaces
adding some wrapper for Jackrabbit
An intermediate step is the generation of a file containg the node type definition in Compact Namespace and Node Type Definition (CND) notation
Inspiring people toshare
Storing actual contentOne way is to store e.g. the text of a text content element as we do today, i.e. as a string
What about links in the text?
To be aware of links, we’d need to parse it and maintain a reference index
A possible syntax:<a href="${link:{uuid:{522c0cac-7d67-4324-869f- 7553426f95b0},repository:{website},workspace:{default},path:{/help/user-mailing-list}}}">some link</a>
Inspiring people toshare
Storing actual contentAn alternative could be to break up the content in smaller nodes
A working example is the DOM tree of a HTML document
Advantages
No need to have a seperate reference index
Queries for links always easily possible
Disadvantages
Adds quite some complexity