Dzień dobry,
Gdyby ktokolwiek szukał gotowych klas / bibliotek do implementacji systemu płatności we własnym rozwiązaniu, to z radością informujemy, że system płatności Transferuj.pl wyszedł na przeciw oczekiwaniom i udostępnił całą bibliotekę, z której można wybierać gotowe rozwiązania do implementacji dowolnych form płatności w systemach ecommerce:
https://github.com/tpaycom/transferuj
Dokumentacje techniczne i inne przykłady dla standardowego systemu są dostępne do pobrania tutaj: https://transferuj.pl/dokumentacje
Dla pozostałych niestandardowych systemów dokumentacje są dostępne na indywidualne żądanie, ponieważ są to systemy dla osób, które wiedzą, czego chcą.
Zachęcamy do testowania i feedbacku. W razie uwag prosimy o komentarz na forum lub na github.
Mamy nadzieję, że oszczędzi to Developerom dużo cennego czasu.
CardAPI
- Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
- Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
- SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
- Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
- Magiczne liczby. Co to jest 40 albo 128?
- Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
- Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej. Jak już to stała jest bardziej odpowiednia do tego.
Curl
- static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania
PaymentBasic
- Po raz kolejny hardcodeing. Ścieżki, IP, URL.
You made my day
Tego komentować nie trzeba.
Co to jest?
Oby to było cokolwiek innego niż XML...
Dalej nie idę, bo jest albo to samo co wcześniej, albo gorzej.
Podsumowująć:
- Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
- Podstawy takie jak autoloading, DI.
- Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
- Generalnie kompletny brak SOLID.
- Testy - a raczej ich kompletny brak.
Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach. Od strony programistycznej jest to gorzej niż kiepsko. Niestety, ale w kwestii płatności nie mógłbym zaufać takiej bibliotece.
- Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
- Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
- SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
- Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
- Magiczne liczby. Co to jest 40 albo 128?
- Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
- Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej. Jak już to stała jest bardziej odpowiednia do tego.
Curl
- static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania
PaymentBasic
- Po raz kolejny hardcodeing. Ścieżki, IP, URL.
You made my day
Tego komentować nie trzeba.Co to jest?
Oby to było cokolwiek innego niż XML...
Dalej nie idę, bo jest albo to samo co wcześniej, albo gorzej.
Podsumowująć:
- Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
- Podstawy takie jak autoloading, DI.
- Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
- Generalnie kompletny brak SOLID.
- Testy - a raczej ich kompletny brak.
Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach. Od strony programistycznej jest to gorzej niż kiepsko. Niestety, ale w kwestii płatności nie mógłbym zaufać takiej bibliotece.
Dziękujemy za komentarze. Na wstępie chcielibyśmy zaznaczyć, że istnieje 10 różnych sposobów implementacji płatności i implementując płatności w dowolnym serwisie w 99,9% należy wybrać jeden sposób i jedno rozwiązanie, a nie wszystkie.
Chcielibyśmy się precyzyjnie odnieść do Pana wypowiedzi:
Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
DI są przydatne, ale istnieją różne wzorce projektowe, a biblioteki są w zamyśle jak najbardziej niezależne od stosowanego wzorca projektowego. Dependency Injection ze względu na prostotę realizowanych przez klasy operacji i ich uniwersalność nie zostały użyte umyślnie.
Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
Zgadza się. Są to typy prymitywne. Z biblioteki będą korzystali programiści systemów z różnymi architekturami. Klasa ma być przede wszystkim łatwa w dopasowaniu do dowolnego systemu.
SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
Znamy SRP, jednakże nie uważamy za dobry pomysł aby rozdzielać funkcjonalności biblioteki na klasy zgodnie z SRP zawsze, wszędzie i bez przemyślenia. Wprowadziliśmy podział na klasy obsługujące poszczególne metody płatności oraz klasy pomocnicze. Nie sztuka w stworzeniu 100 klas zawierających 1-2 metody. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji. Gdyby zaistniała potrzeba dalszego rozwoju klas pod kątem realizowanych przez nie zadań jak najbardziej należałoby je rozdzielić na mniejsze. Takie potrzeby w zamyśle nie powinny się jednak pojawić.
Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
Tu się zgadzamy. Można rozdzielić tą metodę na dwie osobne.
Magiczne liczby. Co to jest 40 albo 128?
40 jest stałą długością ciągu kodu autoryzacyjnego używanego w systemie niezmienną od zawsze (podobnie jak 128). Można wyciągnąć to do const oraz odpowiednio skomentować, tak aby nikt ich nie zmieniał.
Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
Oczywiście, że tak. Nikt bowiem nie zaimplementuje wszystkich tych rozwiązań jednocześnie. Należy wybrać jedno dowolne z tych rozwiązań, najlepsze dla danych potrzeb i je zaimplementować. Tworzenie do tego 10 repozytoriów jest przerostem formy nad treścią.
Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej.
W przypadku zmienności tych parametrów tak, ale one są niezmienne.
Jak już to stała jest bardziej odpowiednia do tego.
Dlaczego nie stała? Gdyby w wyjątkowo rzadkiej sytuacji trzeba było jednak zmienić te ścieżki, to przy tej skali implementacji i tej rzadkości zmian łatwiejsza jest modyfikacja konstruktora niż przerobienie całej klasy
static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania
To zależy od sposobu testowania.
Po raz kolejny hardcodeing. Ścieżki, IP, URL.
Biblioteki mają przyspieszyć, a nie spowalniać programistę. J/w.
You made my day Tego komentować nie trzeba.
Tu zastanawialiśmy się, co poeta miał na myśli? To, że powinien być autoloading? Nie powinien.
Podstawy takie jak autoloading, DI.
Rozumiem że na co dzień nie zajmuje się Pan integracjami bibliotek do istniejących systemów o różnych strukturach? Nie jest możliwa realizacja autoloadingu z całkowitym wyeliminowaniem ryzyka konfliktu z projektem, do którego biblioteka jest dołączana (tak, znamy spl_autoload_register i słyszeliśmy o przestrzeniach nazw). Na wielu hostingach współdzielonych będzie z tym delikatnie mówiąc bardzo duży problem.
Oby to było cokolwiek innego niż XML...
Tak, to jest XML. W temacie wyrażeń regularnych w naszej opinii jest to dobra droga biorąc pod uwagę integrację z zewnętrznymi systemami. Wbudowane metody PHP służące do parsowania odpowiedzi w formacie XML nie zawsze są w stanie poprawnie przetworzyć odpowiedź XML (szczególnie biorąc pod uwagę różne wersje PHP, w których jest wykorzystywana biblioteka, różne systemy kodowania itd.). To rozwiązanie jest zwyczajnie najbardziej niezawodne do tego konkretnego zastosowania.
Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
Ten zarzut jest całkowicie bezpodstawny i niezgodny z rzeczywistością. Biblioteki są standaryzowane. Zastosowane coding standards bibliotek są podobne do Symfony2: http://symfony.com/doc/current/contributin.../standards.html . Jedynie w kodzie z niektórymi krótkimi przykładami zastosowania bibliotek mogą faktycznie być niespójności.
Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
Ponownie static
Funkcje statyczne znajdują się głównie w klasie Util oraz Validate, nie operują na zmiennych lub instancjach obiektów zewnętrznych! A to że nie jest to mile widziane przez testerów jest osobną kwestią. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji.
Generalnie kompletny brak SOLID.
To jest temat do dyskusji dotyczący konkretnych klas i ich precyzyjnych zastosowań.
Testy - a raczej ich kompletny brak.
Tu się zgodzimy - nie ma testów. Mamy je w planach do przygotowania w przyszłości, jeśli będzie takie zapotrzebowanie ze strony użytkowników bibliotek.
Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach
Komentowanie rzeczy odrywając je od ich zastosowania jest jak ocenianie wygody samochodu po jego kluczykach.
Chcielibyśmy się precyzyjnie odnieść do Pana wypowiedzi:
Nie można niczego zamockować, bo cały request opiera się na jednej prywatnej metodzie, która w dodatku używa, a jakby inaczej, static. To samo z logowaniem. O Dependency Injection programiści w firmie nie słyszeli?
DI są przydatne, ale istnieją różne wzorce projektowe, a biblioteki są w zamyśle jak najbardziej niezależne od stosowanego wzorca projektowego. Dependency Injection ze względu na prostotę realizowanych przez klasy operacji i ich uniwersalność nie zostały użyte umyślnie.
Jakieś klasy niby są ale wszystko co wchodzi i wychodzi z metod to typy prymitywne.
Zgadza się. Są to typy prymitywne. Z biblioteki będą korzystali programiści systemów z różnymi architekturami. Klasa ma być przede wszystkim łatwa w dopasowaniu do dowolnego systemu.
SRP. W jednej klasie jest wszystko: request, walidacja, komunikaty błędów.
Znamy SRP, jednakże nie uważamy za dobry pomysł aby rozdzielać funkcjonalności biblioteki na klasy zgodnie z SRP zawsze, wszędzie i bez przemyślenia. Wprowadziliśmy podział na klasy obsługujące poszczególne metody płatności oraz klasy pomocnicze. Nie sztuka w stworzeniu 100 klas zawierających 1-2 metody. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji. Gdyby zaistniała potrzeba dalszego rozwoju klas pod kątem realizowanych przez nie zadań jak najbardziej należałoby je rozdzielić na mniejsze. Takie potrzeby w zamyśle nie powinny się jednak pojawić.
Metody typu 'saleValidateAndPrepareParams'. Sama nazwa już powinna dać programiście do myslenia. O jedno 'and' za dużo.
Tu się zgadzamy. Można rozdzielić tą metodę na dwie osobne.
Magiczne liczby. Co to jest 40 albo 128?
40 jest stałą długością ciągu kodu autoryzacyjnego używanego w systemie niezmienną od zawsze (podobnie jak 128). Można wyciągnąć to do const oraz odpowiednio skomentować, tak aby nikt ich nie zmieniał.
Code duplication. Cała walidacja, włącznie z komunikatami błędów, jest powielana. Parsowanie parametrów i przygotowanie danych do request-u tak samo.
Oczywiście, że tak. Nikt bowiem nie zaimplementuje wszystkich tych rozwiązań jednocześnie. Należy wybrać jedno dowolne z tych rozwiązań, najlepsze dla danych potrzeb i je zaimplementować. Tworzenie do tego 10 repozytoriów jest przerostem formy nad treścią.
Takie rzeczy jak URL czy IP powinny być podawane w parametrze a nie hardcodowane i to w zmiennej.
W przypadku zmienności tych parametrów tak, ale one są niezmienne.
Jak już to stała jest bardziej odpowiednia do tego.
Dlaczego nie stała? Gdyby w wyjątkowo rzadkiej sytuacji trzeba było jednak zmienić te ścieżki, to przy tej skali implementacji i tej rzadkości zmian łatwiejsza jest modyfikacja konstruktora niż przerobienie całej klasy
static? Po raz kolejny. To się kompletnie nie nadaje do przetestowania
To zależy od sposobu testowania.
Po raz kolejny hardcodeing. Ścieżki, IP, URL.
Biblioteki mają przyspieszyć, a nie spowalniać programistę. J/w.
You made my day Tego komentować nie trzeba.
Tu zastanawialiśmy się, co poeta miał na myśli? To, że powinien być autoloading? Nie powinien.
Podstawy takie jak autoloading, DI.
Rozumiem że na co dzień nie zajmuje się Pan integracjami bibliotek do istniejących systemów o różnych strukturach? Nie jest możliwa realizacja autoloadingu z całkowitym wyeliminowaniem ryzyka konfliktu z projektem, do którego biblioteka jest dołączana (tak, znamy spl_autoload_register i słyszeliśmy o przestrzeniach nazw). Na wielu hostingach współdzielonych będzie z tym delikatnie mówiąc bardzo duży problem.
Oby to było cokolwiek innego niż XML...
Tak, to jest XML. W temacie wyrażeń regularnych w naszej opinii jest to dobra droga biorąc pod uwagę integrację z zewnętrznymi systemami. Wbudowane metody PHP służące do parsowania odpowiedzi w formacie XML nie zawsze są w stanie poprawnie przetworzyć odpowiedź XML (szczególnie biorąc pod uwagę różne wersje PHP, w których jest wykorzystywana biblioteka, różne systemy kodowania itd.). To rozwiązanie jest zwyczajnie najbardziej niezawodne do tego konkretnego zastosowania.
Niespójność code style. Raz tak, raz tak. Jak kompu popadło tak pisał.
Ten zarzut jest całkowicie bezpodstawny i niezgodny z rzeczywistością. Biblioteki są standaryzowane. Zastosowane coding standards bibliotek są podobne do Symfony2: http://symfony.com/doc/current/contributin.../standards.html . Jedynie w kodzie z niektórymi krótkimi przykładami zastosowania bibliotek mogą faktycznie być niespójności.
Wszystko upchane w kilku klasach, które robią wszystko i nic operając sie na static.
Ponownie static
Funkcje statyczne znajdują się głównie w klasie Util oraz Validate, nie operują na zmiennych lub instancjach obiektów zewnętrznych! A to że nie jest to mile widziane przez testerów jest osobną kwestią. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji.Generalnie kompletny brak SOLID.
To jest temat do dyskusji dotyczący konkretnych klas i ich precyzyjnych zastosowań.
Testy - a raczej ich kompletny brak.
Tu się zgodzimy - nie ma testów. Mamy je w planach do przygotowania w przyszłości, jeśli będzie takie zapotrzebowanie ze strony użytkowników bibliotek.
Samej funkcjonalności nie oceniam, bo sam wgląd w bibliotekę dyskwalifikuje ją w przedbiegach
Komentowanie rzeczy odrywając je od ich zastosowania jest jak ocenianie wygody samochodu po jego kluczykach.
Dziękujemy za komentarze. Na wstępie chcielibyśmy zaznaczyć, że istnieje 10 różnych sposobów implementacji płatności i implementując płatności w dowolnym serwisie w 99,9% należy wybrać jeden sposób i jedno rozwiązanie, a nie wszystkie.
Oczywiście, że jest wiele sposobów na rozwiązanie tego same problemu. Ale pewne problemy rozwiązuje się zawsze tak samo a dodatkowo nie wszystko co działa jest rozwiązaniem dobrym. Niestety ale prawda jest taka, że "działa" !== "dobre rozwiązanie".
DI są przydatne, ale istnieją różne wzorce projektowe, a biblioteki są w zamyśle jak najbardziej niezależne od stosowanego wzorca projektowego. Dependency Injection ze względu na prostotę realizowanych przez klasy operacji i ich uniwersalność nie zostały użyte umyślnie.
Wzorce projektowe stosuje się, aby ułatwić obsługę, modyfikację i implementację danego rozwiązania. Nie ma czegoś takiego jak "niezależność od wzorców projektowych". Wzorce się stosuje albo nie. Każdy wybór musi być poparty konkretnym za i przeciwi. Osobiście uważam (i znajdzie się więcej taki osó
, że to domyslnie powinno się używać każdego możliwego wzorca chyba, że mamy konkretny powód, który możemy uzasadnić, aby wzorca nie użyć.
Zgadza się. Są to typy prymitywne. Z biblioteki będą korzystali programiści systemów z różnymi architekturami. Klasa ma być przede wszystkim łatwa w dopasowaniu do dowolnego systemu.
A ja zawsze myślałem, że PHP, przynajmniej od wersji 3, zawsze ma classy i możliwość używania obiektów. Przyznam, że przez 10 lat nie spotkałem się z wersją, która by tego nie miał, ale widocznie Państwa zespól wie coś, czego inni nie wiedzą
Wiem, jestem złośliwy. Ale albo Pan nie wie o czym mówi, ale naiwnie wierzy we wszystko co Panu programiści naopowiadali.
O jakiej architekturze tutaj mowa? Klasy i obiekty są zawsze. Ich użycie jest wręcz wskazane, bo urościłoby całą architekturę. Samo-walidujące się obiekty można przekazywać wszędzie i zawsze bez martwienia się o to, czy ich stan jest prawidłowy.
Niestety, ale używanie wszędzie typów prymitywnych to największa bolączka PHP. Na to nie ma innego wytłumaczenia niź "Nie chciało się nam zrobić inaczej, bo trzeba by wklepać kilka linijek kodu więcej".
Znamy SRP, jednakże nie uważamy za dobry pomysł aby rozdzielać funkcjonalności biblioteki na klasy zgodnie z SRP zawsze, wszędzie i bez przemyślenia.
SOLID powinno się stosować zawsze i wszędzie a rezygnować z niego tylko wtedy, kiedy mamy ku temu uzasadnione powody. A nie odwrotnie. Ten projekt nie trzyma się nawet jednej z zasad SOLID. Mówienie, że "w naszym przypadku to bez sensu" wynika raczej z niewiedzy o tym czym jest SOLID i zasada "clean code".
40 jest stałą długością ciągu kodu autoryzacyjnego używanego w systemie niezmienną od zawsze (podobnie jak 128). Można wyciągnąć to do const oraz odpowiednio skomentować, tak aby nikt ich nie zmieniał.
Ja bym nawet powiedział, że trzeba to wyciągnąć do const. W 999 przypadkach na 1000 konetarz jest zbędny. Stała powinna mieć taką nazwę i być użyta w takim kontekście, aby od razu było wiadomo o co chodzi. Tutaj niestety muse się domyślać, albo pytać autora.
Oczywiście, że tak. Nikt bowiem nie zaimplementuje wszystkich tych rozwiązań jednocześnie. Należy wybrać jedno dowolne z tych rozwiązań, najlepsze dla danych potrzeb i je zaimplementować. Tworzenie do tego 10 repozytoriów jest przerostem formy nad treścią.
Code duplication nigdy nie jesto dobry. Tłumaczenie, że "my tego nie porzebujemy" to przyjaw niewiedzy. To jest zawsze złe. I do tego " Tworzenie do tego 10 repozytoriów"? Omal nie spadłem z krzesła. Oddzielne repozytorium na jedną klasę? Serio? Ciekawe podejście. Jam tam takiego nie stosuję, ale to widocznie taka jakas moja fanaberia jest Poza tym, w ostateczności, można to wydobyć do kilku wewnętrznych metod prywatnych, bo kod w 100% identyczny. Niezrobienie tego nie jest wynikiem "takie rozwiązanie wybraliśmy" tylko niedbalstwa.
W przypadku zmienności tych parametrów tak, ale one są niezmienne.
Powodzenia przy pisaniu testów
Dlaczego nie stała? Gdyby w wyjątkowo rzadkiej sytuacji trzeba było jednak zmienić te ścieżki, to przy tej skali implementacji i tej rzadkości zmian łatwiejsza jest modyfikacja konstruktora niż przerobienie całej klasy
Stałą podałem jako ostateczność. To powinno być podane w konstruktorze. By the book. Ale nawet stała jest już lepsza niż zmienna prywatna. Bo to nie jest zmienna. Nie przypisuje się jej innych wartości podczas działania aplikacji.
To zależy od sposobu testowania.
Nie, nie zaleźy. I nawet sami do tego nie napiszecie odpowiednich testów. Bo nie da się niczego nigdzie zamockowac. Jedyne co możecie zrobić, to napisać test integracyjny operujący na rzeczywistych requestach i operacjach, albo hackować widoczność metod na potrzeby testów. Ale niestety to nie wszystko.
Biblioteki mają przyspieszyć, a nie spowalniać programistę. J/w.
DI nie spowalnia programowania. Przynajmniej ja jeszcze takiego czegos w rzyciu nie widziałam. Przyspiesza - owszem.
Tu zastanawialiśmy się, co poeta miał na myśli? To, że powinien być autoloading? Nie powinien.
A na myśli miał to, że takie rzeczy to się robi, na przykład, przez require albo require_once na początku pliku a nie w konstruktorze. Cały ten loader klas można zastąpić prostym require_once na początku pliku. To co jest w tym konstruktorze to jakiś dziwny twór, który ktoś zrobił chyba dla zabawy, bo mu sie nudziało
Rozumiem że na co dzień nie zajmuje się Pan integracjami bibliotek do istniejących systemów o różnych strukturach? Nie jest możliwa realizacja autoloadingu z całkowitym wyeliminowaniem ryzyka konfliktu z projektem, do którego biblioteka jest dołączana (tak, znamy spl_autoload_register i słyszeliśmy o przestrzeniach nazw). Na wielu hostingach współdzielonych będzie z tym delikatnie mówiąc bardzo duży problem.
Nie, nie zajmuje się czymś rakim, ale wiem, jak dział require/include. Twórcy najwidoczniej nie (patrz wyżej).
Tak, to jest XML. W temacie wyrażeń regularnych w naszej opinii jest to dobra droga biorąc pod uwagę integrację z zewnętrznymi systemami. Wbudowane metody PHP służące do parsowania odpowiedzi w formacie XML nie zawsze są w stanie poprawnie przetworzyć odpowiedź XML (szczególnie biorąc pod uwagę różne wersje PHP, w których jest wykorzystywana biblioteka, różne systemy kodowania itd.). To rozwiązanie jest zwyczajnie najbardziej niezawodne do tego konkretnego zastosowania.
UTF-8 działa zawsze i wszędzie. Więc to bardzo kiepski argument. Bardzo chętnie bym zobaczył tą strukturę, co to nie działa w róźnych wersjach PHP. Bo ja się nigdy z czymś takim nie spotkałem a z XML pracuje cały czas...
Ten zarzut jest całkowicie bezpodstawny i niezgodny z rzeczywistością. Biblioteki są standaryzowane. Zastosowane coding standards bibliotek są podobne do Symfony2
- card_api.php
- curl.php
- payment_card.php
- payment_szkwal.php
- payment_white_label.php
Kilka z brzegu. Wszystkie, bez wyjątku, są niezgodne ze standardani Symfony.
Ponownie static Funkcje statyczne znajdują się głównie w klasie Util oraz Validate, nie operują na zmiennych lub instancjach obiektów zewnętrznych! A to że nie jest to mile widziane przez testerów jest osobną kwestią. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji.
Static !== "nie operują na zmiennych lub instancjach obiektów zewnętrznych". Szczególnie klasa curl jest ewidentnym przykładem, że ktoś nie rozumie keidy stosuje sie static a kiedy nie.
Tu się zgodzimy - nie ma testów. Mamy je w planach do przygotowania w przyszłości, jeśli będzie takie zapotrzebowanie ze strony użytkowników bibliotek.
Od kiedy to testy są dla użytkowników biblioteki? One są dla twórców, żeby upewnić się, że to co zrobili działa. Użytkownicy mają dostać kod, który będą mogli łatwo zamockowac do potrzeb własnych testów. Ich na prawdę nie obchodzą wasze testy
Komentowanie rzeczy odrywając je od ich zastosowania jest jak ocenianie wygody samochodu po jego kluczykach.
Kluczykach? Ciekawe Daliście mechanikowi auto na warsztat. Rozebrał je na części pierwsze i nie podoba mu się nawet jeda rzecz którą znalazł. Auto może i jeździ i wprzód i w tył. Może nawet skręca. Ale po co mi jazda próbna, jak nic mi się w tym aucie nie podoba?
Oczywiście, że jest wiele sposobów na rozwiązanie tego same problemu. Ale pewne problemy rozwiązuje się zawsze tak samo a dodatkowo nie wszystko co działa jest rozwiązaniem dobrym. Niestety ale prawda jest taka, że "działa" !== "dobre rozwiązanie".
DI są przydatne, ale istnieją różne wzorce projektowe, a biblioteki są w zamyśle jak najbardziej niezależne od stosowanego wzorca projektowego. Dependency Injection ze względu na prostotę realizowanych przez klasy operacji i ich uniwersalność nie zostały użyte umyślnie.
Wzorce projektowe stosuje się, aby ułatwić obsługę, modyfikację i implementację danego rozwiązania. Nie ma czegoś takiego jak "niezależność od wzorców projektowych". Wzorce się stosuje albo nie. Każdy wybór musi być poparty konkretnym za i przeciwi. Osobiście uważam (i znajdzie się więcej taki osó
, że to domyslnie powinno się używać każdego możliwego wzorca chyba, że mamy konkretny powód, który możemy uzasadnić, aby wzorca nie użyć.Zgadza się. Są to typy prymitywne. Z biblioteki będą korzystali programiści systemów z różnymi architekturami. Klasa ma być przede wszystkim łatwa w dopasowaniu do dowolnego systemu.
A ja zawsze myślałem, że PHP, przynajmniej od wersji 3, zawsze ma classy i możliwość używania obiektów. Przyznam, że przez 10 lat nie spotkałem się z wersją, która by tego nie miał, ale widocznie Państwa zespól wie coś, czego inni nie wiedzą
Wiem, jestem złośliwy. Ale albo Pan nie wie o czym mówi, ale naiwnie wierzy we wszystko co Panu programiści naopowiadali.
O jakiej architekturze tutaj mowa? Klasy i obiekty są zawsze. Ich użycie jest wręcz wskazane, bo urościłoby całą architekturę. Samo-walidujące się obiekty można przekazywać wszędzie i zawsze bez martwienia się o to, czy ich stan jest prawidłowy.
Niestety, ale używanie wszędzie typów prymitywnych to największa bolączka PHP. Na to nie ma innego wytłumaczenia niź "Nie chciało się nam zrobić inaczej, bo trzeba by wklepać kilka linijek kodu więcej".
Znamy SRP, jednakże nie uważamy za dobry pomysł aby rozdzielać funkcjonalności biblioteki na klasy zgodnie z SRP zawsze, wszędzie i bez przemyślenia.
SOLID powinno się stosować zawsze i wszędzie a rezygnować z niego tylko wtedy, kiedy mamy ku temu uzasadnione powody. A nie odwrotnie. Ten projekt nie trzyma się nawet jednej z zasad SOLID. Mówienie, że "w naszym przypadku to bez sensu" wynika raczej z niewiedzy o tym czym jest SOLID i zasada "clean code".
40 jest stałą długością ciągu kodu autoryzacyjnego używanego w systemie niezmienną od zawsze (podobnie jak 128). Można wyciągnąć to do const oraz odpowiednio skomentować, tak aby nikt ich nie zmieniał.
Ja bym nawet powiedział, że trzeba to wyciągnąć do const. W 999 przypadkach na 1000 konetarz jest zbędny. Stała powinna mieć taką nazwę i być użyta w takim kontekście, aby od razu było wiadomo o co chodzi. Tutaj niestety muse się domyślać, albo pytać autora.
Oczywiście, że tak. Nikt bowiem nie zaimplementuje wszystkich tych rozwiązań jednocześnie. Należy wybrać jedno dowolne z tych rozwiązań, najlepsze dla danych potrzeb i je zaimplementować. Tworzenie do tego 10 repozytoriów jest przerostem formy nad treścią.
Code duplication nigdy nie jesto dobry. Tłumaczenie, że "my tego nie porzebujemy" to przyjaw niewiedzy. To jest zawsze złe. I do tego " Tworzenie do tego 10 repozytoriów"? Omal nie spadłem z krzesła. Oddzielne repozytorium na jedną klasę? Serio? Ciekawe podejście. Jam tam takiego nie stosuję, ale to widocznie taka jakas moja fanaberia jest
Poza tym, w ostateczności, można to wydobyć do kilku wewnętrznych metod prywatnych, bo kod w 100% identyczny. Niezrobienie tego nie jest wynikiem "takie rozwiązanie wybraliśmy" tylko niedbalstwa.W przypadku zmienności tych parametrów tak, ale one są niezmienne.
Powodzenia przy pisaniu testów
Dlaczego nie stała? Gdyby w wyjątkowo rzadkiej sytuacji trzeba było jednak zmienić te ścieżki, to przy tej skali implementacji i tej rzadkości zmian łatwiejsza jest modyfikacja konstruktora niż przerobienie całej klasy
Stałą podałem jako ostateczność. To powinno być podane w konstruktorze. By the book. Ale nawet stała jest już lepsza niż zmienna prywatna. Bo to nie jest zmienna. Nie przypisuje się jej innych wartości podczas działania aplikacji.
To zależy od sposobu testowania.
Nie, nie zaleźy. I nawet sami do tego nie napiszecie odpowiednich testów. Bo nie da się niczego nigdzie zamockowac. Jedyne co możecie zrobić, to napisać test integracyjny operujący na rzeczywistych requestach i operacjach, albo hackować widoczność metod na potrzeby testów. Ale niestety to nie wszystko.
Biblioteki mają przyspieszyć, a nie spowalniać programistę. J/w.
DI nie spowalnia programowania. Przynajmniej ja jeszcze takiego czegos w rzyciu nie widziałam. Przyspiesza - owszem.
Tu zastanawialiśmy się, co poeta miał na myśli? To, że powinien być autoloading? Nie powinien.
A na myśli miał to, że takie rzeczy to się robi, na przykład, przez require albo require_once na początku pliku a nie w konstruktorze. Cały ten loader klas można zastąpić prostym require_once na początku pliku. To co jest w tym konstruktorze to jakiś dziwny twór, który ktoś zrobił chyba dla zabawy, bo mu sie nudziało
Rozumiem że na co dzień nie zajmuje się Pan integracjami bibliotek do istniejących systemów o różnych strukturach? Nie jest możliwa realizacja autoloadingu z całkowitym wyeliminowaniem ryzyka konfliktu z projektem, do którego biblioteka jest dołączana (tak, znamy spl_autoload_register i słyszeliśmy o przestrzeniach nazw). Na wielu hostingach współdzielonych będzie z tym delikatnie mówiąc bardzo duży problem.
Nie, nie zajmuje się czymś rakim, ale wiem, jak dział require/include. Twórcy najwidoczniej nie (patrz wyżej).
Tak, to jest XML. W temacie wyrażeń regularnych w naszej opinii jest to dobra droga biorąc pod uwagę integrację z zewnętrznymi systemami. Wbudowane metody PHP służące do parsowania odpowiedzi w formacie XML nie zawsze są w stanie poprawnie przetworzyć odpowiedź XML (szczególnie biorąc pod uwagę różne wersje PHP, w których jest wykorzystywana biblioteka, różne systemy kodowania itd.). To rozwiązanie jest zwyczajnie najbardziej niezawodne do tego konkretnego zastosowania.
UTF-8 działa zawsze i wszędzie. Więc to bardzo kiepski argument. Bardzo chętnie bym zobaczył tą strukturę, co to nie działa w róźnych wersjach PHP. Bo ja się nigdy z czymś takim nie spotkałem a z XML pracuje cały czas...
Ten zarzut jest całkowicie bezpodstawny i niezgodny z rzeczywistością. Biblioteki są standaryzowane. Zastosowane coding standards bibliotek są podobne do Symfony2
- card_api.php
- curl.php
- payment_card.php
- payment_szkwal.php
- payment_white_label.php
Kilka z brzegu. Wszystkie, bez wyjątku, są niezgodne ze standardani Symfony.
Ponownie static
Funkcje statyczne znajdują się głównie w klasie Util oraz Validate, nie operują na zmiennych lub instancjach obiektów zewnętrznych! A to że nie jest to mile widziane przez testerów jest osobną kwestią. Obecny podział jest czytelny dla programistów, którzy będą korzystali z biblioteki dla potrzeb integracji.Static !== "nie operują na zmiennych lub instancjach obiektów zewnętrznych". Szczególnie klasa curl jest ewidentnym przykładem, że ktoś nie rozumie keidy stosuje sie static a kiedy nie.
Tu się zgodzimy - nie ma testów. Mamy je w planach do przygotowania w przyszłości, jeśli będzie takie zapotrzebowanie ze strony użytkowników bibliotek.
Od kiedy to testy są dla użytkowników biblioteki? One są dla twórców, żeby upewnić się, że to co zrobili działa. Użytkownicy mają dostać kod, który będą mogli łatwo zamockowac do potrzeb własnych testów. Ich na prawdę nie obchodzą wasze testy
Komentowanie rzeczy odrywając je od ich zastosowania jest jak ocenianie wygody samochodu po jego kluczykach.
Kluczykach? Ciekawe
Daliście mechanikowi auto na warsztat. Rozebrał je na części pierwsze i nie podoba mu się nawet jeda rzecz którą znalazł. Auto może i jeździ i wprzód i w tył. Może nawet skręca. Ale po co mi jazda próbna, jak nic mi się w tym aucie nie podoba?
Właśnie integruję naszą platformę B2B z transferuj. Biblioteki oszczędziły mi ładnych parę godzin rzeźbienia. Szukałem dodatkowego info o bibliotece i wpadłem na ten wątek. LOL, co ty za bzdury wpisujesz, ja nie miałem żadnego problemu w wykorzystaniu ich biblioteki.
Bzdury:
- Domyślnie powinno się używać KAŻDEGO możliwego wzorca
- Wiem, jestem złośliwy
- Niestety, ale używanie wszędzie typów prymitywnych to największa bolączka PHP
- Stałą podałem jako ostateczność. To powinno być podane w konstruktorze. By the book
- DI nie spowalnia programowania. Przynajmniej ja jeszcze takiego czegos w rzyciu nie widziałam
Odnośnie autoloadingu to już nie wierze co czytam. Najpierw piszesz o autoloadingu, wyśmiewając zaproponowane rozwiązanie. Dowiedziałeś się jaki jest problem (bo wcześniej nie wiedziałeś o problemie, ponieważ jak napisałeś nie realizujesz integracji) to już nie piszesz o autoloadingu tylko o require/include.
Trolling level master!
W temacie XML: „Bo ja się nigdy z czymś takim nie spotkałem a z XML pracuje cały czas...” To że się nigdy nie spotkałeś pokazuje tylko Twój duży brak doświadczenia. Ja wiem że w pokoju, w którym pracujesz siedzi dużo senior dev'ów ale to że siedzisz z nimi nie czyni Cię jednymi z nich.”
To co napisałeś na końcu odnośnie mechanika jest tak głupie i bezsensowne, że nawet nie wiem o co chodzi.
Transferuj wychodzi do przodu tworząc bibliotekę, która może się przydać programistom podczas implementacji, prosi o sensowane uwagi a ty trollujesz temat. Daj sobie spokój i wyjdź z piwnicy (https://www.youtube.com/watch?v=9nFGtq_iBQg)
Faktycznie mi też brakuje testów, ale gotowych, zrealizowanych przez nich. Szczerze, musiałbym na głowę upaść, żeby siedzieć i pisać testy pod zewnętrzne biblioteki.
Bzdury:
- Domyślnie powinno się używać KAŻDEGO możliwego wzorca
- Wiem, jestem złośliwy
- Niestety, ale używanie wszędzie typów prymitywnych to największa bolączka PHP
- Stałą podałem jako ostateczność. To powinno być podane w konstruktorze. By the book
- DI nie spowalnia programowania. Przynajmniej ja jeszcze takiego czegos w rzyciu nie widziałam
Odnośnie autoloadingu to już nie wierze co czytam. Najpierw piszesz o autoloadingu, wyśmiewając zaproponowane rozwiązanie. Dowiedziałeś się jaki jest problem (bo wcześniej nie wiedziałeś o problemie, ponieważ jak napisałeś nie realizujesz integracji) to już nie piszesz o autoloadingu tylko o require/include.
Trolling level master!
W temacie XML: „Bo ja się nigdy z czymś takim nie spotkałem a z XML pracuje cały czas...” To że się nigdy nie spotkałeś pokazuje tylko Twój duży brak doświadczenia. Ja wiem że w pokoju, w którym pracujesz siedzi dużo senior dev'ów ale to że siedzisz z nimi nie czyni Cię jednymi z nich.”
To co napisałeś na końcu odnośnie mechanika jest tak głupie i bezsensowne, że nawet nie wiem o co chodzi.
Transferuj wychodzi do przodu tworząc bibliotekę, która może się przydać programistom podczas implementacji, prosi o sensowane uwagi a ty trollujesz temat. Daj sobie spokój i wyjdź z piwnicy (https://www.youtube.com/watch?v=9nFGtq_iBQg)
Faktycznie mi też brakuje testów, ale gotowych, zrealizowanych przez nich. Szczerze, musiałbym na głowę upaść, żeby siedzieć i pisać testy pod zewnętrzne biblioteki.
Dzień dobry,
minęło już sporo czasu od kiedy stworzyliśmy pierwsze biblioteki do PHP https://github.com/tpay-com/tpay-php i opublikowaliśmy informacje na tym forum. Dziękujemy za komentarze. Chcielibyśmy zaznaczyć, iż większość wcześniejszych uwag jest już nieaktualna.
Od tego czasu biblioteki bardzo się powiększyły i zostały gruntownie zrefaktoryzowane.
Obecnie zawierają one Dependency Injection, autoloading (uznaliśmy, że nie musimy już wspierać najstarszych wersji PHP), jedynie w pojedynczych miejscach (w loggerze) stosowane są static'i. Staramy się, aby kod spełniał zasady SOLID. Duplikacja kodu została wyeliminowana, całe biblioteki spełniają PSR-2 i są poddawane analizie statycznej przed każdym commitem.
Przy okazji chcieliśmy dodać, że Transferuj.pl zmieniło nazwę na Tpay.com w grudniu 2015 roku - tu prośba do moderatora forum o dodanie Tpay.com w temacie, ponieważ nikt już raczej nie szuka w internecie bibliotek Transferuj.pl, a pod hasłem biblioteki php Tpay.com nie pojawia się ten wątek.
Zachęcamy do ponownego komentowania i życzymy miłego dnia,
Tpay.com
minęło już sporo czasu od kiedy stworzyliśmy pierwsze biblioteki do PHP https://github.com/tpay-com/tpay-php i opublikowaliśmy informacje na tym forum. Dziękujemy za komentarze. Chcielibyśmy zaznaczyć, iż większość wcześniejszych uwag jest już nieaktualna.
Od tego czasu biblioteki bardzo się powiększyły i zostały gruntownie zrefaktoryzowane.
Obecnie zawierają one Dependency Injection, autoloading (uznaliśmy, że nie musimy już wspierać najstarszych wersji PHP), jedynie w pojedynczych miejscach (w loggerze) stosowane są static'i. Staramy się, aby kod spełniał zasady SOLID. Duplikacja kodu została wyeliminowana, całe biblioteki spełniają PSR-2 i są poddawane analizie statycznej przed każdym commitem.
Przy okazji chcieliśmy dodać, że Transferuj.pl zmieniło nazwę na Tpay.com w grudniu 2015 roku - tu prośba do moderatora forum o dodanie Tpay.com w temacie, ponieważ nikt już raczej nie szuka w internecie bibliotek Transferuj.pl, a pod hasłem biblioteki php Tpay.com nie pojawia się ten wątek.
Zachęcamy do ponownego komentowania i życzymy miłego dnia,
Tpay.com
Organizacja plików w paczce to jakas masakra... Wygląda to jakby ktoś wrzucił pliki tam gdzie mu się podobało. Nazwy też jakieś takie na siłę.
W tworzeniu paczek composera jeszcze sporo się musicie nauczyć.
W tworzeniu paczek composera jeszcze sporo się musicie nauczyć.
Dziękujemy za komentarz. Czy może Pan podać jak wg Pana nazwy plików powinny być ustandaryzowane, gdyż obecnie staraliśmy się, aby wszystkie nazwy mówiły same za siebie.
Biblioteki działają i aktualizują się przez Composera i sami z tego korzystamy przy tworzeniu dodatków https://tpay.com/integracja-w-sklepach . Nie natrafiliśmy przy tym na żadne trudności z nazwami w czasie ich używania.
Główne klasy znajdują się tutaj i ich nazwy są wymowne https://github.com/tpay-com/tpay-php/tree/m...src/_class_tpay
Przykłady również odnoszą się bezpośrednio do oferowanych przez nas metod płatności: https://github.com/tpay-com/tpay-php/tree/m...ayLibs/examples
Oczywiście jeśli możemy zrobić coś lepiej, to chętnie dowiemy się, jak dokładnie możemy ułatwić prace osobom, które niekoniecznie tak szczegółowo jak my znają nasze rozwiązania.
Prosimy zatem o bardziej szczegółowe wskazówki poprawek, które wg Pana powinniśmy zastosować.
Biblioteki działają i aktualizują się przez Composera i sami z tego korzystamy przy tworzeniu dodatków https://tpay.com/integracja-w-sklepach . Nie natrafiliśmy przy tym na żadne trudności z nazwami w czasie ich używania.
Główne klasy znajdują się tutaj i ich nazwy są wymowne https://github.com/tpay-com/tpay-php/tree/m...src/_class_tpay
Przykłady również odnoszą się bezpośrednio do oferowanych przez nas metod płatności: https://github.com/tpay-com/tpay-php/tree/m...ayLibs/examples
Oczywiście jeśli możemy zrobić coś lepiej, to chętnie dowiemy się, jak dokładnie możemy ułatwić prace osobom, które niekoniecznie tak szczegółowo jak my znają nasze rozwiązania.
Prosimy zatem o bardziej szczegółowe wskazówki poprawek, które wg Pana powinniśmy zastosować.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.