Global navigation

   Documentation Center
   eZ Studio & eZ Platform
     User Manual
     Technical Manual
     Glossary
   eZ Publish 4.x / legacy

 
eZ Publish (5.x)

eZ Publish 5.x | For eZ Platform & eZ Studio topics see Technical manual and User manual, for eZ Publish 4.x and Legacy topics see eZ Publish legacy

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

This tutorial aims at covering the conception and development of a custom eZ Publish 5 FieldType.

We will do this by implementing a Tweet Field Type. It will:

About Field Types

They are the most granular building block for content managed by eZ Publish. Quite a few are shipped by default (https://confluence.ez.no/display/EZP/FieldTypes).
They are responsible for:

  • storing data, either using the native storage engine mechanisms, or specific means

  • validating input data

  • making the data searchable (if applicable)

  • displaying an instance of the type

Custom FieldTypes are a very powerful type of extension, since they allow you to hook deep into the content model.

You can find the in-depth documentation about FieldTypes and their best practices.

Tutorial Steps

The bundle

FieldTypes, like any other eZ Publish 5 extensions, must be provided as Symfony 2 bundles. This chapter will cover the creation and organization of this bundle

Read more about Creating the bundle and structuring the bundle.

 API

This part will cover the implementation of the eZ Publish API elements required to implement a custom FieldType

Read more about implementing the API.

Converter

Storing data from any FieldType into the Legacy Storage Engine requires that your custom data is mapped to the data model. This part will cover the implemention of the storage converter for the Tweet FieldType.

Templating

Displaying a FieldType's data is done through a twig template.

Read more about implementing the FieldType template.

 Custom storage

Whenever a FieldType must store more than the basic primitives the API supports, custom, external storage must be implemented. This part covers how a FieldType can store custom data anywhere, in particular into custom tables in the legacy database.

  • No labels