[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"
obsolete.
* 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
unfortunately).
[1]
https://review.typo3.org/#/c/24980/3/Classes/TYPO3/TYPO3CR/Domain/Model/Workspace.php
[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
the REST API.
[4]
https://git.typo3.org/Packages/TYPO3.Neos.git/blob/HEAD:/Classes/TYPO3/Neos/Controller/Service/NodeController.php
--
Bastian Waidelich
--
Core Developer Team
TYPO3 .... inspiring people to share!
Get involved: typo3.org
More information about the Neos
mailing list