Closed Idziak closed 3 years ago
dbojdo
commented
3 years ago Widzę, że pracowaliśmy nad tym samym równocześnie. Wydaje mi się, że moja implementacja jest nieco prostsza (nie wymaga dodatkowych kontenerów na or / and / not) i dodatkowo wspiera zagnieżdżone warunki (co prawda nie wiem czy API też to wspiera, ale jakby co, to jest). Zobacz proszę na mój PR: https://github.com/dbojdo/wFirma/pull/18
Idziak
commented
3 years ago Też zmierzałem w Twoim kierunku pierwotnie, ale zdecydowałem się na wydzielenie kontenerów, żeby móc uzyskać strukturę
`
<or>
....
</or> Czwarty przykład z dokumentacji z sekcji "Konstruowanie zapytań find". Jeżeli api przyjmowało by zagnieżdżone zapytania, można by rzeczywiście dodatkowe kontenery pominąć(uzyskalibyśmy ten sam efekt), ale tego nie jestem pewien, trzeba przetestować :) Inna kwestia, na sucho nie jestem pewien jak JMS zachowa się dla [tej](https://github.com/dbojdo/wFirma/pull/18/commits/6a60e9ad5f96f00423005fae78fd618d6b48b1b7#diff-ac57306053e95cd48dd8fd62b1b10ca81fe5af55f407b91497ce0152f4586141R28) definicji. Czy dzieci nie będą zawszezamiast
dbojdo
commented
3 years ago Przy takiej implementacji zawsze buduje się poprawna struktura tyle, że z tego co próbowałem, API nie obsługuje warunków zagnieżdżonych (czasem je ignoruje, czasem dostajesz pusty response bez żadnego XML'a). Przykład serializacji zagnieżdżonych warunków jest w teście tests/Entity/Parameters/ParametersSerializerTest.php
Do rozważenia implementacja fabryk
\Webit\WFirmaSDK\Entity\Parameters\Conditions- czy powinien być dostępny do stworzenia pusty obiekt.