Basic architecture and repository organisation - Jackalope2/jackalope GitHub Wiki

  • The jackalope2/jackalope repository contains the core parts.
  • Have jackalope2/jackalope-jackrabbit and jackalope2/jackalope-doctrine-dbal and so on for storage adapters
  • Split phpcr-utils into jackalope2/query, jackalope2/... repositories

Class naming

  • TODO: Figure out whether storage adapters live in \Jackalope\Storage\Jackrabbit and so on or in \JackalopeJackrabbit\Storage
  • TODO: Decide if we keep appending Interface to interfaces

Architecture

A class per PHPCR artifact, interacting with each other. Have a UnitOfWork (part of what ObjectManager is now). Also have a look at what ocramius is building, e.g. https://github.com/Ocramius/ChangeSet

Nodes

Only have one representation of Nodes throughout the application. We probably need an extened interface for internal methods e.g. to update properties without validation (Versioning has to update a lot of protected properties for example). See Storage Adapters and Node instantiation

Factory / Service Container

Maybe we should make the factory usage more explicit, as in createNode and then use a __call method that determines the class name. This could then be used to overwrite the most common calls with explicit methods for performance, and would make it a lot more convenient to override specific classes.

Or we could go with a more radical approach. We currently do mostly dependency injection, but not consequently, and its all hardcoded in a couple of classes. A DI container might make this more elegant and also more flexible to plug or not plug certain functionalities.

See for example https://github.com/jackalope/jackalope/pull/285#discussion_r31403374