So far, our Field Type=E2=80=99s value is represented by the Tweet=
\Value class. It holds a semantic representation of the type=E2=80=
=99s data: a url, author url and the tweet's content.
The next step is to tell the system how to actually store = this.
Unlike eZ Publish Legacy, eZ Platform supports (by design) multiple stor= age engines. The main, and almost only one right now is the Legacy Storage = Engine, based on the legacy database, with a new implementation. Since each= storage engine may have its own way of storing data, we need to map each F= ield Type value to something legacy can understand. To do this, we will imp= lement a Field Type Converter, each storage engine defining its own interfa= ce for those.
The legacy storage engine uses the ezcontentobject_attribute table to store Field values, and ezcontentclass_attribute to store Field definition values (settings, etc.). They're both based on =
the same principle. Each row represents a Field or a FieldDefinition, and o=
ffers several free fields, of different types, where the type can store its=
data:
ezcontentobject_attribute offers three fields for this p=
urpose: data_int , data_text and data_=
float ezcontentclass_attribute offers a few more: four d=
ata_int (data_int1 to data_int4) fields, f=
our data_float (data_float1 to data=
_float5) ones, and five data_text (data_text1 to data_text5) .Each type is free to use those fields in any way it requires. Converters= will map a field=E2=80=99s semantic values to the fields described above, = for both settings (validation + configuration) as well as value.
The Converter will be placed along with the Type and Value definitions (=
the Kernel stores them inside the Legacy Storage Engine structure): =
eZ/Publish/FieldType/Tweet/LegacyConverter.php . A Legacy Converter=
must implement the eZ\Publish\Core\Persistence\Legacy\Content\FieldValue\C=
onverter interface:
namespace EzSystems\TweetFieldTypeBundle\eZ\Publish\FieldType\Tweet=
;
use eZ\Publish\Core\Persistence\Legacy\Content\FieldValue\Converter;
class LegacyConverter implements Converter
{
}=20
The Converter interface expects us to implement five methods:
toStorageValue() and toFieldValue()
used to convert an API field value to a legacy sto=
rage value, and a legacy storage value to an API field value.
toStorageFieldDefinition() and toFieldDefinition(=
)
used to convert a field definition t=
o a legacy one, and a stored legacy field definition to an API field defini=
tion.
getIndexColumn()
Tell the=
API which legacy DB field should be used to sort & filter content, eit=
her sort_key_string or sort_key_int
As said above, those two methods are used to convert from a Field to a v= alue that Legacy can store, and the other way around.
We have defined that we wanted to store the tweet=E2=80=99s URL in username-sta=
tus-tweetid string we extract in getName() and =
getSortInfo().
toStorageValue() will fill the provided eZ\Publish\Co=
re\Persistence\Legacy\Content\StorageFieldValue from a Tweet\=
Value, while toFieldValue() will do the exact opposite=
:
use eZ\Publish\Core\Persistence\Legacy\Content\StorageFieldValue;
use eZ\Publish\SPI\Persistence\Content\FieldValue;
// [...]
public function toStorageValue( FieldValue $value, StorageFieldValue $stora=
geFieldValue )
{
$storageFieldValue->dataText =3D $value->url;
$storageFieldValue->sortKeyString =3D $value->sortK=
ey;
}
public function toFieldValue( StorageFieldValue $value, FieldValue $fieldVa=
lue )
{
$fieldValue->url =3D $value->dataText;
$fieldValue->sortKey =3D $value->sortKeyString;
}
=20
With these two methods, the legacy storage engine is able to convert a <=
code>Tweet\Value into legacy data, and legacy data back into a =
Tweet\Value object.
toStorageFieldDefinition() and =
toFieldDefinition()The first two methods we have implemented apply to a Field=E2=80=99s val= ue . But we also need to convert our Field=E2=80=99s definition. For exampl= e, a TextLine=E2=80=99s max length, or any FieldDefinition option.
This is done using toStorageDefinition() that converts a StorageFieldDefinition. =
;toFieldDefinition() does the opposite. In our case, we actual=
ly don=E2=80=99t need to implement those methods since our Tweet Type doesn=
=E2=80=99t have settings:
use eZ\Publish\Core\Persistence\Legacy\Content\StorageFieldDefiniti=
on;
use eZ\Publish\SPI\Persistence\Content\Type\FieldDefinition;
// [...]
public function toStorageFieldDefinition( FieldDefinition $fieldDef, Storag=
eFieldDefinition $storageDef )
{
}
public function toFieldDefinition( StorageFieldDefinition $storageDef, Fiel=
dDefinition $fieldDef )
{
}=20
getIndexColumn()In toFieldValue() and toStorageValue() we ha=
ve used the sortKeyString property from StorageFieldV=
alue. getIndexColumn() will tell provide the legacy st=
orage engine the type of index / sort column it should use: string (s=
ort_key_string) or int (sort_key_int). Depending on whi=
ch one is returned, the system will either use the sortKeyString or the sortKeyInt properties from the StorageField=
Value.
public function getIndexColumn()
{
return 'sort_key_string';
}=20
Just like a Type, a Legacy Converter needs to be registered and tagged i= n the service container.
The tag is ezpublish.storageEngine.legacy.converter, a=
nd it requires an alias attribute to be set to the Field =
Type identifier (eztweet). Let's add this block to
services:
ezsystems.tweetbundle.fieldType.eztweet.converter:
class: EzSystems\TweetFieldTypeBundle\eZ\Publish\FieldType\Tweet\Le=
gacyConverter
tags:
- {name: ezpublish.storageEngine.legacy.converter, alias: eztwe=
et}=20