eZ
...
Platform API Repository
This entity is the entry point to everything you will do with the Public API.
It will allow you to create, retrieve, update and delete all the eZ Publish Platform objects, as well as content typesContent Types, sectionsSections, content Content states. It is always obtained through the service container.
| Code Block | ||||
|---|---|---|---|---|
| ||||
/** @var $repository \eZ\Publish\API\Repository\Repository $repository = $container->get( 'ezpublish.api.repository' ); |
By itself, the repository doesn't do much. It allows three type types of operations: user authentication (getting / changing the current user), issuing transactions, and obtaining services.
| Tip | ||
|---|---|---|
| ||
Pay attention to the inline phpdoc block in this code stub. It tells your IDE that |
The service container
The above code snippet implies that the service container is available in the context you are writing your code in.
In controllers, this generally is done by extending the Symfony Controller class. It comes with a get() method that calls the service container. In command line scripts, it requires that you extend the ContainerAwareCommand base class instead of Controller. This class provides you with a getContainer() method that returns the service container.
| Info | ||
|---|---|---|
| ||
In order to make it even easier to obtain the repository from controllers code, eZ Publish 5 Platform controllers extend a custom Controller class that provides a You can and should of course do the same in your custom controllers. |
Authentication
One of the responsibilities of the Repository is user authentication. Every action will be executed as a user. In the context of a normal eZ Publish Platform execution, the logged in user will of course be the current one, identified via one of the available authentication methods. This user's permissions will affect the behavior of the Repository. The user may f.e. for example not be allowed to create Content, or view a particular sectionSection.
Logging in to the Repository is covered in the other recipes of the Cookbook.
Services
The main entry point to the repository's features are services. The Public API breaks down access to Content, User, Content Types , etc and other features into various services. Those services are obtained via the Repository, using getServiceName get[ServiceName]() like methods: getContentService() , getUserService() , etc...
Throughout the Cookbook, you will be guided through the various capabilities those services have, and how you can use them to implement your projects.
...
While Services provide interaction with the repository, the elements (Content, Users) they provide interaction with are provided as read-only Value Objects, in the eZ\Publish\Core\Repository\Values namespace. Those objects are broken down into sub-namespaces: Content, ContentType, User and ObjectState, each sub-namespace containing a set of value objects, such as Content\Content or User\Role .
These objects are read-only by design. They are only meant to be used in order to fetch data from the repository. They come with their own properties, such as $content->id, $location->hidden, but also with methods that provide access to more , related information, such as Relation::getSourceContentInfo() or Role::getPolicies(). By design, a value object will only give you access to data that is very closely related to it. More complex retrieval operations will require you to use the appropriate Service, using information from your Value Object.
...
Some complex Value Objects have an Info counterpart, like ContentInfo, the counterpart for Content. These objects are specific , and provide you with lower-level information. For instance, ContentInfo will provide you with currentVersionNo or remoteId, while Content will let you retrieve Fields, the ContentTypeContent Type, or previous Versions.
They are provided by the API, but are read only, can't be modified and sent back. Creation and modification of Repository values are is done using Create structs and Update structs.
...