This entity is the entry point to eve= rything you will do with the Public API.
It will allow you to create, retrieve= , update and delete all the eZ Publish objects, as well as content types, s= ections, content states. It is always obtained through the service containe= r.
/** @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 type of operations: user authentication (gettin= g / changing the current user), issuing transactions, and obtaining service= s.
Pay attention to the inline phpdoc bl=
ock in this code stub. It tells your IDE that $repository=
is an instance of \eZ\Publish\API\Repository\Repository.=
If your IDE supports this feature, you will get code completion on the&nbs=
p;$repository object. This helper is a huge time saver wh=
en it comes to learning about the eZ Publish API.
The above code snippet implies that t= he service container is available in t= he context you are writing your code in.
In controllers, this generally is don=
e by extending the Symfony Controller class. It comes with a=
get() method that calls the service container. I=
n command line scripts, it requires that you extend the ContainerAwa=
reCommand base class instead of Controller. This class provides you with a getContainer() met=
hod that returns the service container.
Getting the repository from eZ Publish 5 controllers
In order to make it even easier to ob=
tain the repository from controllers code, eZ Publish 5 controllers extend =
a custom Controller class that provi=
des a getRepository() method which directly retur=
ns the repository from the service container.
You can and should of course do the s= ame 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 Publish execution, the logged in user will of course be the cu= rrent one, identified via one of the available authentication methods. This= user's permissions will affect the behavior of the Repository. The user ma= y f.e. not be allowed to create Content, or view a particular section.
Logging in to the Repository is covered in the recipes of the Cookbook.<= /p>
The main entry point to the repository's features are services. The Publ=
ic API breaks down access to Content, User, Content Types, etc features int=
o various services. Those services are obtained via the Repository, using getServi=
ceName() like methods: getContentService(),&=
nbsp;getUserService()...
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=
namespace. Those objects are broken down into sub-namespaces:&=
nbsp;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 properti=
es, such as $content->id, $location->hidden=
, but also with methods that provide access to more, related information, s=
uch as Relation::getSourceContentInfo() or Role::getPoli=
cies(). 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 Val=
ue Object.
Some complex Value Objects have an Info counterpart, like Con=
tentInfo, the counterpart for Content. These objec=
ts 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 ContentType, =
or previous Versions.
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 are 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;getContentCreateStruct() method that returns a new&nbs=
p;ContentCreateStruct object. Equivalent methods exist fo=
r UpdateStruct objects as well, and for most Value Objects.
Using them is also covered in the Cookbook.