Skip to content

Conversation

AntePrkacin
Copy link

@AntePrkacin AntePrkacin commented Oct 16, 2025

Updated the whole bundle to use Ibexa v5. Fixed a few small things - mostly changed some method definitions and updated database gateway.

Also, I've removed the ibexa-forms-bundle from require-dev section and included ibexa/solr bundle there because it is used in bundle/Core/Search/Solr/Query/CriterionVisitor/EnhancedSelection.php file.

In tests.yml file (used for GitHub Actions), the PHP version has been updated to 8.3 and Symfony version to 7.3. Right now, the tests are failing because the ibexa-forms-bundle is removed from composer.json file.

@AntePrkacin AntePrkacin requested a review from emodric October 16, 2025 07:16
@AntePrkacin AntePrkacin self-assigned this Oct 16, 2025
public function storeFieldData(VersionInfo $versionInfo, Field $field, array $context): ?bool
public function __construct(Gateway $gateway)
{
$this->gateway = $gateway;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a dynamic property?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In field_types.yaml file, the injected class here is DoctrineStorage, which extends an abstract class Gateway. I added the constructor here because of 'potentially polymorphic call` warning.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did the warning come from? The constructor is already in Ibexa\Contracts\Core\FieldType\GatewayBasedStorage abstract class and it doesn't make sense to repeat it here.


public function handle(CriteriaConverter $converter, QueryBuilder $queryBuilder, Criterion $criterion, array $languageSettings): string
{
/**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

superflous PHPDoc. This method does not throw anything and all @param and @return are already declared in method signature itself.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look at the method declaration in the abstract class, it has a PHPDoc which says that it throws an InvalidArgumentException. Also, in the method itself, the $this->getFieldDefinitionIds() method is called, which throws an InvalidArgumentException.

I added the PHPDoc first and foremost to say that the CriterionInterface param is actually EnhancedSelectionCriterion class. If that's alright with you, I would just keep this info in PHPDoc and remove everything else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine.

As for @throws, we should not specify those if the method does not directly throw. Otherwise, we might put every throw on every method ever :D


public function visit(Criterion $criterion, ?CriterionVisitor $subVisitor = null): string
/**
* @param EnhancedSelectionCriterion $criterion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unneeded @param here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @param here is needed because it specifies that the CriterionInterface param is actually an instance of EnhancedSelectionCriterion class

/**
* @param EnhancedSelectionCriterion $criterion
*
* @throws InvalidArgumentException
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use FQCN in PHPDocs.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May I ask why? I understand that there might be cases where it would be better (clearer) to use FQCN in PHPDocs, but here both classes are already imported and used elsewhere in this class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of reasons:

  1. It's our coding standard
  2. Consistency with cases where classes are not already imported
  3. It is much clearer and more readable to have a FQCN here, and it keeps code separate from comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants