Expose field type constant and update documentation

[VincentLanglet]

Subject

I am targeting this branch, because BC.

This allow to be used in project or others bundle.
Maybe these constant are better somewhere else, you'll say.

This will avoid using non-existent field type, like
https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Guesser/TypeGuesser.php#L36
https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Guesser/TypeGuesser.php#L68

I also updated lot of documentation.

Changelog

### Added
- Added `TemplateRegistry::TYPE_*` constant to be used instead of string value.
- Added `format` option for `time` field type.

### Deprecated
- Deprecated `smallint` type for template ; use `integer` instead.
- Deprecated `bigint` type for template ; use `integer` instead.
- Deprecated `decimal` type for template ; use `float` instead.
- Deprecated `text` type for template ; use `string` instead.

[VincentLanglet]

@greg0ire I added a note

[phansys]

Maybe these constant are better somewhere else, you'll say.

What about create something like ShowMapperInterface for these constants?

[VincentLanglet]

Maybe these constant are better somewhere else, you'll say.

What about create something like ShowMapperInterface for these constants?

These constant will be both used for the showMapper and the listMapper. I don't think creating two string constants (and so on) in two differents classes would be benefit.

For SHOW and LIST, I think that type is mainly (only ?) used to select the right template. In this bundle, we currently used the constants only to register the available ones.

So I tried to use a single class, with template-context.
I also prefer to use a real class rather an interface, because if someone try to implement all our interface in a different way and use a different syntax, these templates may not exist anymore.

[phansys]

I understood. Just I think the templating concept is not the best choice here, but I really don't have any better option at first glance 🤔

[VincentLanglet]

I understood. Just I think the templating concept is not the best choice here, but I really don't have any better option at first glance 🤔

Yeah for sure.

In FieldDescriptionInterface comment say:

Returns the field type, the type is a mandatory field as it used to select the correct template or the logic associated to the current FieldDescription object.

For List/show, type is used

• Fore some 'actions' === $type or \in_array($type, ['actions', 'batch', 'select'], true) checks
• For $this->builder->addField($this->list, $type, $fieldDescription, $this->admin) which is implemented in DoctrineORMAdminBundle for example, and only set the template.
• For setting a class class="sonata-ba-list-field-header-{{ field_description.type }}

I see a big difference between filter and form in which type are real class string like StringFilter::class or DateType::class and between show and list in which type are just a keyword to select the right template.

In a dream world, maybe we should expose and use some StringShowType::class, StringListType::class, where a Type class would refer to a template. But that's so much refactoring and possible BC-break for not so much benefit.

Creating these constants seems to be the best benefit/work ratio.

[VincentLanglet]

Do you still request change @phansys ? :)