So far, our type=E2=80=99s va=
lue is represented by the Tweet\Value class. It holds a semant=
ic representation of the type=E2=80=99s data: an url, and author url, and t=
he tweet's content.
The next step is to tell the system h= ow to actually store this.
Unlike eZ Publish Legacy, eZ Publish = 5 supports (by design) multiple storage engines. The main, and almost only one right now is the Legacy Stora= ge 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 FieldType value to somethi= ng legacy can understand. To do this, we will implement a FieldType Convert= er, each storage engine defining its own interface for those.
The legacy storage engine uses the ezcontentobject_attribute table to store field values, =
and ezcontentclass_attribut=
e to store field definitio=
n values (settings, etc). They're both based on the same principle. Each ro=
w reprensents a Field or a FieldDefinition, and offers 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 =
data_int (data_int1 to data_int4) =
fields, four 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 wi=
th 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\Con=
verter 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() & =
toFieldValue()
used t=
o convert an API field value to a legacy storage value, and a legacy storag=
e value to an API field value.
toStorageFieldDefinition() & toFieldDef=
inition()
used to convert a=
field definition to a legacy one, and a stored legacy field definition to =
an API field definition
getIndexColumn()
Tell the API which legacy DB field should be used to sort & fi=
lter content, either sort_key_string or sort_key_int
As said above, those two methods are = used to convert from a Field to a value Legacy can store, and the other way= around.
We have defined that we wanted to sto=
re the tweet=E2=80=99s URL in data_text, and that sorting woul=
d be done on the username-status-tweetid string we extract in =
getName()getSortInfo().&nb=
sp;
toStorageValue() will fill the provided eZ\Publish\Core\Persistence\Legacy\Content\StorageFieldValue from a Tweet\Value, while toFieldVal=
ue() will do the exact opp=
osite:
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 st=
orage engine is able to convert a =
Tweet\Value into legacy data, and legacy data back into =
a Tweet\Value object.
toStorageFieldDefinition() a=
nd toFieldDefinition()The first two methods we have impleme= nted apply to a Field=E2=80=99s v= alue. But we also need to convert= our Field=E2=80=99s definition. For example, a TextLine=E2=80=99s max leng= th, or any FieldDefinition option.
This is done using toStorageDef=
inition(), that converts a FieldDefinition into a StorageFieldDefinition. toFieldDefinition() does the opposite. In our case, we act=
ually don=E2=80=99t need to implement those methods since our Tweet Type do=
esn=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
getInd=
exColumn()In toFieldValue()toStorageValue(), we have used the StorageFieldValue. 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 sortKeyI=
nt properties from the StorageFieldValue.
public function getIndexColumn()
{
return 'sort_key_string';
}=20
Just like a Type, a Legacy Conv= erter needs to be registered and tagged in the service container.
The tag is ezpublish=
.storageEngine.legacy.converter, and it requires an alias=
attribute to be set to the FieldType identifier (eztweet). Let's add this block to =
Resources/config/services.yml:
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