The PHP API is also commonly referred to as the "Public API". C= urrently it exposes a Repository which allows you to create, read= , update, manage and delete all objects available in eZ Platform, first and= foremost content, but also related objects like Sections, Locations, Conte= nt Types, Content Type groups, languages and so on.
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 Plat= form objects, as well as Content Types, Sections, Content states. It is alw= ays obtained through the service container.
/** @var $repository \eZ\Publish\API\Repository\Repository $repository =3D $container->get( 'ezpublish.api.repository' );=20
By itself, the repository doesn't do much. It allows three types o= f operations: user authentication (getting / changing the current user), is= suing transactions, and obtaining services.
Pay attention to the inline phpdoc block in this code stub. It tells you=
r IDE that $repository is an instance of $repository object.=
This helper is a huge time saver when it comes to learning about the eZ Pl=
atform API.
The above code snippet implies that the service container is available in the context you are writing your cod= e in.
In controllers, this generally is done by extending the Symfony get() &nbs=
p;method that calls the service container. In command line scripts, it requ=
ires that you extend the ContainerAwareCommand bas=
e class instead of Controller. This class provides you wi=
th a getContainer() method that returns the service =
container.
Getting the repository from eZ Platform controllers
In order to make it even easier to obtain the repository from controller=
s code, eZ Platform controllers extend a custom Controller class that provide=
s a getRepository() method which directly retu=
rns the repository from the service container.
You can and should of course do the same in your custom controllers.
One of the responsibilities of the Repository is user authentication. Ev= ery action will be executed as a user. In the context of= a normal eZ Platform execution, the logged in user will of course be the c= urrent one, identified via one of the available authentication methods. Thi= s user's permissions will affect the behavior of the Repository. The user m= ay for example not be allowed to create Content, or view a particular Secti= on.
Logging in to the Repository is covered in other recipes of the Cookbook= .
The main entry point to the repository's features are services. The Publ=
ic API breaks down access to Content, User, Content Types and other feature=
s into various services. Those services are obtained via the Repository, using <=
code>get[ServiceName]() methods: g=
etContentService() , getUserService() , etc.
Throughout the Cookbook, you will be guided through the various capabili= ties those services have, and how you can use them to implement your projec= ts.
While Services provide interaction with the repository, the elements (Co=
ntent, Users) they provide interaction with are provided as read-only =
Value Objects in the eZ\Publish\Core\Repository\Values<=
/code> namespace. Those objects are broken down into sub-namespaces:&n=
bsp;Content, ContentType, User and ObjectState, each sub-namespace containing =
a set of value objects, such as Content\Content <=
/a> 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 properti=
es, such as $content->id, $location->hidden=
, but also with methods that provide access to more related information, su=
ch as Relation::getSourceContentInfo() or Role::getPolic=
ies(). By design, a value object will only give you access to data t=
hat is very closely related to it. More complex retrieval operations will r=
equire you to use the appropriate Service, using information from your Valu=
e Object.
Some complex Value Objects have an They are provided by the API, but are read only, c=
an't be modified and sent back. Creation and modification of Repository val=
ues is done using Create structs and Update structs. In order to update or create elements in the Repository, you will use st=
ructs. They are usually provided by the Service that manages the Value Obje=
cts you want to alter or create. For instance, the Content service has a&nb=
sp; Using them is also covered in the Cookbook.Info counterpart, like&n=
bsp;ContentInfo, the counterpart for Content=
. These objects are specific and provide you with lower-level information. =
For instance, ContentInfo will provide you with remoteId, while Content will let you retrieve Fields, the Content Type, or previous Versions.
Create and update =
structs
getContentCreateStruct() method that returns a new&nbs=
p;ContentCreateStruct object. Equivalent methods exist fo=
r UpdateStruct objects as well, and for most Value Objects.