findologic / findologic-api Goto Github PK

• We're using the validation library Valitron for validating submitted input by users of the library. This includes
  • Adding parameters such as ->setUrl().
  • Validating the submitted Findologic config. This affects the service URL.
• There is a bug at the moment that prevents us from validating URLs, because the Validation can not handle objects as URLs and may throw an exception.

Add URL handling for those who need it if the bug is fixed at our validation library.

Please note: This issue does not have a high priority since this bug only occurs when using the library in a bad way.

When sending navigation requests the initial parameter (the category) is set. Since this is a key feature for navigation, this parameter needs to be implemented before we can roll out our first beta version.

This parameter is the same as attrib, except it should be setted, since you can only have one of those.

Describe the bug
The use of autocompleteBlocks for the suggest request is not possible.

How to reproduce
Steps to reproduce the behavior:

1. Create a new SuggestRequest
2. Add a autocomplete block with the method addAutocompleteBlocks
3. A internal error occured

What happens

1. The function addAutocompleteBlocks expects a string value and adds the value directly to the param.
2. The url for the api expects an array of autocomplete blocks but get a single value.
3. An internal error occurde.
4. The second call of the function addAutocompleteBlocks overrides the first value because the internal use of array_merge_recursive (findologic/findologic-api/src/Requests/Request.php:addParam) gets two strings and returns null.

Expected behavior
A valid response is expected.

Screenshots

Environment details:

• PHP version: 7.4
• Version/Branch 1.6.0

Additional context
Workaround:
Use the method addIndividualParam like
->addIndividualParam(
SuggestQueryParameter::AUTOCOMPLETEBLOCKS,
[BlockType::ORDERNUMBER_BLOCK],
SuggestRequest::ADD_VALUE
)

Examples should be in the README.md and in the Wiki

• How do I start?
• How do I get the data that I need?
• I want to display filters how can I archive that?
• I want to be able to request the autocomplete, how can I do that?
• Examples should be simple enough to test. They also should
  • Show images of the result
  • Show the output of variables as comments
• The code should also refer to the Wiki with the @see tags from PhpDoc.

At the moment the ParameterBuilder is taking care of config parameters and request parameters. Sine these are two entirely different things, let's separate them into their own classes.

To make the test better readable we should try to build up the expected data as a data structure and then use assertEquals. This will also give us a nice diff view of expected and actual data when the test fails.

It probably makes more sense to rewrite the FindologicApi to a RequestFactory, that takes care of the requests. There should be three more Objects SearchRequest, NavigationRequest and SuggestionRequest. The FindologicApi should have three methods createSerachRequest, createNavigationRequest and createSuggestionRequest which will return the corresponding Objects. The objects should know their required parameters and timing info. It probably makes sense to create an abstract class for the Objects.

• As an user of this library I want to consume my selected filters easily.
• When I tell the ParameterBuilder to set a specific filter I also want it to be selected in the response.
• Add a flag to each filter to tell weither it is selected or not. The value should be based on what was submitted to FINDOLOGIC such as attrib['cat']=Jeans. The flag may just be an indicator such as $selected and can be getted with $filter->isSelected() which may return true or false.

Relevant is

• Request parameters
• Response objects/additional properties
• (Validating the Response against some Json schema)*

*Maybe it is also useful to validate the Json from FINDOLOGIC again, but I am unsure if it makes sense or not, since FINDOLOGIC should always respond with correctly validated data. Also if the search response will be updated, a response might cause an exception since it is no longer schema conform.

• Requests can now be sent in a modernized request format https://service.findologic.com/ps/centralized-frontend/spec/.
• All requests should be updated to use the new request format.

For users of the library it would be great to have some Smart Did You Mean helper functions. You should be able to get the type, e.g. improved/ corrected and constants for it should exist in Definitions.

• getType(): Returns the type of the query. Either improved or corrected.
• getOriginalQuery(): The original query from the XML response.
• getAlternativeQuery(): If it was a did you mean suggestion use the didYouMeanQuery, otherwise take the queryString.

For reference take a look at:
https://github.com/findologic/plugin-shopware-unified/blob/e7bdb0be052e12bb1cc166803bc4bab94eb4a66f/FinSearchUnified/Helper/StaticHelper.php#L830

• Use phan instead of php-cs-fixer.
  • In Composer.
  • In Tests.

autocompleteblocks can be used to limit the number of requests autocomplete blocks. This parameter is currently not supported.

The following badges etc. need to be updated:

• Travis CI
• Codeclimate
• Codecov
• Packagist

• We have a client.
• We should follow the PSR-18 HTTP Client standard.
• As base construct use: https://packagist.org/packages/psr/http-client - Guzzle may already require it.

The timing related fields are instance variables of FindologicApi while an instance of FindologicApi can fire multiple requests. This is a mismatch, since the timing is related to the requests, not the FindologicApi instance, which is basically a factory for requests.

This is probably fine for now. In the future FindologicApi could be refactored to actually be a request factory, and then the timing info would be attached to the request class instances.

• Sometimes as a consumer (should not happen that often) it may be good to have an endpoint where I can get the raw response that FINDOLOGIC returned.
• The abstract class Response should have some kind of function to get the raw response data.

• There is already an empty class for JSON responses.
• Add implementation that JSON objects are being generated as already is done in XML.