Quantcast
Viewing all articles
Browse latest Browse all 293842

Create a TextWidgetBase

#1758622: Provide the options list of an entity field adds some more redundancies in TextareaWidget and TextfieldWidget, therefore the creation of a TextWidgetBase was proposed.

There is also quite some amount of redundancy (13 lines) in each of:
- core/modules/entity_reference/lib/Drupal/entity_reference/Plugin/field/widget/AutocompleteWidgetBase.php
- core/modules/email/lib/Drupal/email/Plugin/field/widget/EmailDefaultWidget.php
- core/modules/link/lib/Drupal/link/Plugin/field/widget/LinkWidget.php
- core/modules/number/lib/Drupal/number/Plugin/field/widget/NumberWidget.php
(- core/modules/taxonomy/lib/Drupal/taxonomy/Plugin/field/widget/TaxonomyAutocompleteWidget.php)
- core/modules/telephone/lib/Drupal/telephone/Plugin/field/widget/TelephoneDefaultWidget.php
and there might be some more to come (while TaxonomyAutocompleteWidget would be soon based on AutocompleteWidgetBase).

The redundancy is related to the placeholder functionality, and is not surprising because all of these finally are textfields with additional logic.
So the question is if we want to create a common TextWidgetBase for all of these seven widgets.
This would mean that TextWidgetBase had to live in Field module's space. Alternatively, we need all of the other field modules depend on text module, which is required anyway.

But then there is the remaining 11 lines of redundancy between TextareaWidget::errorElement and TextfieldWidget::errorElement that isn't shared with all the others.
With traits being no option in PHP 5.3, we might want to implement both a GenericTextWidgetBase and a more focussed TextWidgetBase.

What do you think is the best solution? I'll be providing a patch then.


Viewing all articles
Browse latest Browse all 293842

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>