kyberman wrote:

Hi Eleo,

  • Be careful about basic mistakes that your IDE tells you about:
    • throw new Exception without backslash or import means the class doesn't need to be loaded. Use throw new \Exception instead.
    • Possibly undefined or never used variables like $field_obj = $index->getField($field_id); are usually grayed inside IDE.
  • Be careful about the context where you initialize a variable - doing that before a foreach could result in a weird situation when you need something isolated to a current loop.
  • Be careful about when you need to log an error and when to output it for the user to see immediately.
    • Also, set the exception message for the user to see, instead of logging only, it's usually more descriptive than e.g. Exception when calling listSchemaFields().
  • Try to have your functions as small as possible, rather than the big you have there.
  • Inside the create function you set the database connection, so the getDatabaseConnection with direct \Drupal::database() call is not needed, you can rely on $this->connection.
  • Instead of $collectionApi->listCollections()->getCollections() and then foreach, just call $collectionApi->getCollection($this->configuration['collection_id']).
  • Exception handling is still terrible (e.g. huge try blocks, "submitConfigurationForm" function, or throw an exception inside catch block), please read something about that topic.
  • Backend config scheme definition inside YAML is missing (I know, this is not there yet also for Recombee).
  • The Recommended branch is 1.0.x - every time you push there, the existing 1.0.x-dev release is updated automatically. There is no reason yet to create new branches like 1.1.x or new 1.1.x-dev release every time you merge a patch (I saw the issue where you created that because of a composer cache problem, but that was not the real issue).
    • Unfortunately, it's not possible to delete a branch having a release, so please be careful about doing these operations and stop pushing to 1.0.x and 1.x.
    • When you are ready for a non-dev release, it will be named 1.1.0-alpha1 or later the full release 1.1.0.

Additionally:

  • "client instance should be created only once (e.g. inside constructor) - move it to the class property"
    • nothing changed here, I still can see 4 (x2) instances created every time
    • I would create "config" and "client" class properties, to be filled inside the "create" function
  • validateConfigurationForm:
    • logging is not necessary for the validation

Please review my patch with few minimal changes and ask if something is not clear.

CommentFileSizeAuthor
search_api_sajari-1.1.x-review.patch11.13 KBeleonel

Comments

eleonel created an issue. See original summary.

  • eleonel committed 706899c on 1.1.x
    Issue #3193671 by kyberman: Code standar issues
    

eleonel credited kyberman.

eleonel’s picture

Status: Active » Needs work

  • eleonel committed 706899c on 1.0.x
    Issue #3193671 by kyberman: Code standar issues
    
eleonel’s picture

Status: Needs work » Closed (won't fix)
kyberman’s picture

Version: 1.1.x-dev » 1.0.x-dev
Status: Closed (won't fix) » Fixed

It looks much better now, thank you.

eleonel’s picture

Last note: I would prefer "isset" instead of "array_key_exists" if there is not a real reason for the second one. See the reason below:

if (!array_key_exists('fields', $form[$form_detail])) { vs. if (!isset($form[$form_detail]['fields'])) {

Difference between isset() and array_key_exists() Function: The main difference between isset() and array_key_exists() function is that the array_key_exists() function will definitely tells if a key exists in an array, whereas isset() will only return true if the key/variable exists and is not null. Also isset() doesn’t render error when array/variable does not exist, while array_key_exists does.

  • eleonel committed 1efbc35 on 1.0.x
    Issue #3193671 by eleonel, kyberman: Code standar issues
    
eleonel’s picture

Status: Fixed » Closed (fixed)

Hi Vit, I pushed a fix for the isset vs array_key_exists issue.