[Neos] Common interface for Node & NodeData?

Bastian Waidelich bastian at typo3.org
Thu Oct 31 19:22:41 CET 2013

Bastian Waidelich wrote:
> is there a reason why there is no common interface for NodeData and Node?
> We don't use them consistently at the moment. e.g.
> Workspace::publishNodes() expects an array of NodeInterface but gets an
> array of NodeData from Workspace::publish().

FYI: This has been fixed and merged in the meantime (see [1]).

Still, I skimmed through the code again and found a lot of duplicated 
code that sometimes seems to interact with the TYPO3CR on the wrong 
level of abstraction.

I started to collect direct interactions with the NodeDataRepository[2]. 
I think all of those should be replaced by (partly higher level) 
interactions with some central service (which then should be the only 
authority dealing with NodeData instances and the NodeDataRepository).

I'm not being pedantic but I think it's vitally important to have a 
solid API for the Content Repository from the start in order to avoid a 
mess later on. This will also make it much easier to streamline the 
client/server communication into some (REST) service that will be usable 
by 3rd parties at some point.

Some measures towards a stable API I could imagine:

1. Encapsulate NodeDataRepository calls into a service

I'll call it "NodeService" for now.

2. Merge functions with similar functionality

If you look at the list of "lookup" interactions at [2] you can see that 
we do similar jobs multiple times. I would suggest following changes:

* Replace Workspace arguments by ContextInterface arguments (and provide 
some easy way to retrieve a context from a workspace if we see the need 
for it). This will also render arguments like "$includeRemovedNodes" 

* The service should only return NULL, NodeInterface or 
QueryResultInterface<NodeInterface> if possible[3]

3. Extend the Neos "Node REST API" [4] so that it provides common 
operations (using the NodeService)

4. Replace existing client/server interactions (ExtDirect, possibly some 
Backend\*Controller) by interactions with the REST API

This is probably quite some work. But I think at least 1. and partly 2. 
could be doable for 1.0.

Sorry for this long post (again) - but I think this is quite important 
and I'd love to hear your opinion (and plans - maybe you have discussed 
the whole thing already, I couldn't join some of the recent meetings 


[2] http://forge.typo3.org/issues/53257#note-1

[3] The latter won't be easy because we'd have to rework all repository 
methods to use QOM/DQL). This would allow us to skip "$limit" and 
"$offset" arguments and to provide some custom filtering/pagination for 


Bastian Waidelich
Core Developer Team

TYPO3 .... inspiring people to share!
Get involved: typo3.org

More information about the Neos mailing list