EA3 is a horror to extend. Please fix.

[rishta]

The problem: autocomplete in EA3 doesn't work well and cannot be easily extended.

Suppose I have a entity Customer(phone, name, lastname, email, ...). I want to use Customer in a create form for an Order:

case Crud::PAGE_NEW:
    yield AssociationField::new('customer', false)
        ->setCrudController(CustomersController::class)
        ->formatValue(fn ($value, Customer $customer): string => $customer->getSearchValue())
        ->autocomplete()
    ;

formatValue makes the autocomplete database query match whatever the closure returns (in my case I want to search in phone number and full name). However, there's the second part of that, because the query results are NOT returned to the client using this same method, but are passed to **final class** EntityDto with this naïve implementation:

    public function toString(): string
    {
        if (null === $this->instance) {
            return '';
        }

        if (method_exists($this->instance, '__toString')) {
            return (string) $this->instance;
        }

        return sprintf('%s #%s', $this->getName(), substr($this->getPrimaryKeyValueAsString(), 0, 16));
    }

This final class is used in another final class EntityPaginator. This class does implement EntityPaginatorInterface, but there is no AbstractEntityPaginator, so it cannot be extended short of reimplementing the whole interface. At this point I am forced to code the whole autocomplete by hand, because the built-in one is inconsistent and I cannot inject my EntityDto into the logic to fix it.

I understand SOLID etc., but this kind of carelessness in making final classes is insane! Completely closing such functionality without leaving any abstraction makes DependencyInjection noting but a feeble dream of a madman. The library loses all extensibility.

Two point conclusion:

• EA3 still has a number of design inconsistencies,
• EA3 is badly written and not easily extensible.

[sc0rp10]

I agree some your concerns, but there's a lot of workarounds to say "badly written".

For example, you can easily ovveride AbstractCrudController::autocomplete() to make the code according your logic. Alternatively you can listen to AfterEntitySearchEvent and modify QueryBuilder as you need.

Do you have any ideas to modify autocompletes?

[rishta]

Regarding your suggestions:

• rewriting the whole autocomplete is exactly what should be avoided
• the second suggestion doesn't even approach the problem.

This feature is half baked to the point of food poisoning. Yes, IT IS BADLY WRITTEN, because it forces the developer firstly - to take care of such inconsistencies, secondly - to reinvent the wheel instead of using IC.

My suggestion is:

• make the presentation configurable in the same way the "searchable presentation" in my example is configurable, or better yet:,
• make the presentation consistent with query by coupling the output format to the search format

How:

• inherit current final classes from abstracts and extract interfaces, so that dependency injection can be used and composition is DRY,
• add interface to formatValue() in AbstractEntityDto (for example),
• or AutocompleteDto extends AbstractEntityDto implements AutocompleteDtoInterface
• appropriately hint return values in that interface, so that components get consistent data from custom formatters.
• ???
• Profit!

Currently "Easy" is not an attribute of this package.

[parijke]

@rishta I look forward to your pull request

[javiereguiluz]

@rishta I'm sorry this project doesn't fit your needs. Luckily there are many other open source projects that you could try. E.g. for Symfony apps you have SonataAdminBundle and Api Platform Admin. Cheers!

[rishta]

A very French approach to criticism. Déjalo. XD

ApiPlatform has the same closed "design" as EasyAdmin: example - not possible to add HTTP methods (LINK, UNLINK) as extension. No, thanks.