Download the PHP package kaliop/ezobjectwrapperbundle without Composer

On this page you can find all versions of the php package kaliop/ezobjectwrapperbundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package ezobjectwrapperbundle

eZObjectWrapperBundle

A Symfony Bundle for eZPlatform / eZPublish 5 development (>=5.3).

Developed by the Kaliop team.

Description

This bundle offers a simple model to organize all the "business logic" code which deals with eZPublish Location and Content objects, keeping it away from Controllers, Commands and other application layers which relate to the Framework.

This way, if you change the definition of one of your ContentTypes, you will not have to hunt across the whole codebase to apply fixes but, ideally, change the code only in one place.

It also tries to adopt patterns which are familiar to Symfony developers who have not used eZPublish before. NB: if you are a Symfony developer please read the This is not your grandpa's ORM chapter further down to help avoid common pitfalls.

How it works

The bundle provides an Entity Manager service, which is used to retrieve Repository services. For each specific type of Content, a different Repository service is used.

Repository services are used to hold the logic to fetch Entities. A typical Repository method would be f.e. getLastTenModified().

Entity instances provide a lazy-loading wrapper for Contents and Locations. They are supposed to hold the logic to decode data from the Content Fields, and to fetch related Entities (without overloading the view Controller and creating a new kernel request). They are generally not configured as Symfony services (for a starter, they are not singletons).

Developers are supposed to create a new Repository and Entity class for each of the Content Types in use in the website; the easiest way to do so is to subclass the existing ones and just add in the custom business logic.

The twig helper

This bundle also provides a Twig function, renderLocation, which uses the ViewController as a service, and doesn't relaunch the Symfony kernel, for faster execution.

Installation

The recommended way to install this bundle is through Composer.

Usage

Retrieving Entities

There are many more methods available in the Repository, you can retrieve an Entity by id, Content, Location, LocationId and even Remote Ids.

Calling methods or attributes of an Entity in Twig

Twig function render_location

This does render a Location without using a separate Controller and reloading the kernel

Creating your own Entities and Repositories

Let's imagine you want to handle the 'newsletter' content type.

  1. Create an Entity class:

  2. Create a Repository class, which relates to that:

  3. Register the Repository with the Entity Manager

    (Note that this is "plain" configuration, it does not have to be in parameters)

  4. Test that it works

  5. Add new methods to the Entity and Repository classes

Advanced Usage

Registering new Repositories as services

We have seen above how to register a php class as Repository. Another way to register classes as repositories is to use tagged Symfony services. The main advantage that you get in exchange for a little bit more configuration is that you can now inject configuration settings into the repository.

Example:

Then, inside the Acme\AcmeBundle\Repository class, you can use the settings member:

NB: if you want to make sure that the settings injected into your custom Repository are always valid, you simply have to implement the validateSettings method

Passing configuration settings into the Entities

Since Entity classes are not registered as Symfony services, injecting settings into Entity instances might seem problematic at first instance. The enrichEntityAtLoad method is available in Repository classes for that purpose.

Allowing an Entity to generate URLs to its Location view

For this common scenario, Traits are made available, to be added to bot Repository an Entity classes

Allowing an Entity to render RichText fields as html

RichText fields need the help of a Symfony service to convert their xml content to html. Again, Traits are made available for that, to be added to bot Repository an Entity classes.

Allowing an Entity to fetch related Entities

A common usecase is when, given an instance of an Entity, you want to fetch its related object(s) as Entities too. A Trait is available for this case as well:

Kaliop\eZObjectWrapperBundle\Core\Traits\RelationTraversingEntity

Just add it to your Entity class and you will be able to use 2 new methods to retrieve the contents of its object relation(s) fields:

$relatedEntity = $this->getRelation('fieldName');
$relatedEntitiesArray = $this->getRelations('anotherFieldName');

Impact with the caches (a.k.a. don't shoot yourself in the foot)

When using the render_location twig helper, or using subclasses of Entity which fetch other Content objects in helper methods, be aware that you are introducing caching dependencies.

eZPublish by default goes to great lengths to make sure that the caches which keep the 'html version' of Content objects are automatically expired whenever the objects are edited. One might say that view-cache-expiration is the prime reason for using Symfony sub-requests when displaying a list of Content objects.

Whenever you end up displaying a Location which is not the current one, remember to add its Id to the X-Location-Id header in your main controller response, so that eZPublish will know when to clear its cache.

For more details see: https://doc.ez.no/display/EZP/HttpCache

This is not your grandpa's ORM

The EntityManager, Repository and Entity classes in eZObjectWrapper have only a vague resemblance with their counterparts in the Doctrine ORM. Please do not assume that you can use them the same way.

F.e., at the moment:

Contact

E-mail : [email protected] / [email protected]

License Latest Stable Version Total Downloads

Build Status Scrutinizer Code Quality Code Coverage


All versions of ezobjectwrapperbundle with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4
ezsystems/ezpublish-kernel Version >=5.3|>=2014.03
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package kaliop/ezobjectwrapperbundle contains the following files

Loading the files please wait ....