Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [lib] Konwersja tablic do obiektów i na odwrót, Według schematu danych
wookieb
post 29.08.2013, 18:17:48
Post #1





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




Dziś wydałem pierwszą wersję bardzo przydatnej biblioteki do wszelkiego rodzaju API (i nie tylko).

https://packagist.org/packages/wookieb/zorro-data-schema

Jej zadaniem jest konwersja tablic na obiekty (konwersja typów danych itd) i na odwrót.
Bardzo przydatne gdy chcecie zmapować przychodzące JSON-a na obiekty albo też wygenerować JSON-a na podstawie obiektu.
Oczywiście zamiast JSON-a może być użyty po drodze zupełnie inny format danych.

Biblioteka przetestowana w 95%.

Zorro Data Schema będzie użyte z moim kolejnym narzędziu do budowania RPC (szybsze i wygodniejsze niż SOAP)
https://github.com/wookieb/zorro-rpc

Bardzo proszę o uwagi, pytania (niektóre z nich wraz z odpowiedziami umieszczę w FAQ), oceny oraz czepianie się "mojego angielskiego", który jak widać nie jest perfekcyjny.


--------------------
Go to the top of the page
+Quote Post
Crozin
post 29.08.2013, 19:22:48
Post #2





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


1. Skorzystaj z nazewnictwa byte, short, int, long zamiast byte, int16, int32, int64.
2. Dlaczego miałbym skorzystać z Twojej biblioteki zamiast z popularnej (albo przynajmniej popularniejszej) JMS\Serializer? wink.gif
Go to the top of the page
+Quote Post
wookieb
post 29.08.2013, 19:50:47
Post #3





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




1) Ciekawa propozycja ale "long long" źle brzmi. Aczkolwiek przemyślę jeszcze raz Twoją propozycje bo jest bardzo ciekawa smile.gif
2) Docelowo powstanie parę innych konwerterów w innych językach (na początek javascript, scala), więc dzięki jednemu schematowi danych możesz szybko określić interfejs aplikacji (API) co w przypadku JMS/serializer jest niemożliwe. Poza tym JMS serializer wymaga zdefiniowania przez Ciebie wszystkich konwersji ręcznie a tak to można to zrobić znaczniej szybciej i wygodniej za pomocą schematu smile.gif Choć nie oszukujmy się, że do takich celów jak REST api, JMS/Serializer(Bundle) będzie bardziej przydatny.


--------------------
Go to the top of the page
+Quote Post
Crozin
post 30.08.2013, 15:26:25
Post #4





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


1. Ale "long long" musiałbyś użyć dopiero przy 128-bitowej liczbie. wink.gif
Cytat
Docelowo powstanie parę innych konwerterów w innych językach (na początek javascript, scala), więc dzięki jednemu schematowi danych możesz szybko określić interfejs aplikacji (API) co w przypadku JMS/serializer jest niemożliwe.
Czyli powstanie kilka klonów tej biblioteki dla różnych platform, gdzie wszystkie będą korzystać z dokładnie tych samych plików YAML jako swoich schematów? Dobrze!
Cytat
Poza tym JMS serializer wymaga zdefiniowania przez Ciebie wszystkich konwersji ręcznie a tak to można to zrobić znaczniej szybciej i wygodniej za pomocą schematu
Mógłbyś pokazać przykład czegoś takiego? Bo chyba nie za bardzo rozumiem co masz na myśli.
Go to the top of the page
+Quote Post
wookieb
post 30.08.2013, 22:01:23
Post #5





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




Cytat(Crozin @ 30.08.2013, 16:26:25 ) *
1. Ale "long long" musiałbyś użyć dopiero przy 128-bitowej liczbie. wink.gif

long long to int64 http://pl.wikipedia.org/wiki/Liczba_ca%C5%...ta_(typ_danych)

Cytat(Crozin @ 30.08.2013, 16:26:25 ) *
Czyli powstanie kilka klonów tej biblioteki dla różnych platform, gdzie wszystkie będą korzystać z dokładnie tych samych plików YAML jako swoich schematów? Dobrze!

Dokładnie smile.gif Będa się tylko różnić plikami opisującymi szczegóły implementacji

Cytat(Crozin @ 30.08.2013, 16:26:25 ) *
Mógłbyś pokazać przykład czegoś takiego? Bo chyba nie za bardzo rozumiem co masz na myśli.


Żeby osiągnąć coś takiego w jms/serializer potrzebowałbym bawić się w coś takiego

  1. // schemat obiektu User zdefiniowany w YAML-u
  2. $serializer = JMS\Serializer\SerializerBuilder::create()
  3. ->setDebug(true)
  4. ->addDefaultDeserializationVisitors()
  5. ->addDefaultSerializationVisitors()
  6. ->addDefaultHandlers()
  7. ->addMetadataDir('serializer')
  8. ->configureHandlers(function (JMS\Serializer\Handler\HandlerRegistry $registry) {
  9. $registry->registerHandler('deserialization', 'UserStatus', 'json',
  10. function ($visitor, $obj, array $type) {
  11. // ręczna tworzenie emulacji ENUM-a
  12. return 1;
  13. }
  14. );
  15.  
  16. $registry->registerHandler('deserialization', 'collection_address', 'json', function() {
  17. // ręczne tworzenie kolekcji obiektów Address
  18. });
  19. })
  20.  
  21. ->build();
  22.  
  23. $json = json_encode(array(
  24. 'name' => 'Łukasz',
  25. 'registrationDate' => '2013-08-30T22:47:02+0200',
  26.  
  27. 'status' => 'ACTIVE',
  28. ));
  29. $result = $serializer->deserialize($json, 'User', 'json');


W przypadku Zorro Data Schema nie ma takiego problemu
  1. // z tablicy na obiekt
  2. $schema->getType('User')->create($data);
  3.  
  4. // z obiektu na tablice
  5. $schema->getType('User')->extract($userObject); // json_encode i gotowe


--------------------
Go to the top of the page
+Quote Post
Crozin
post 30.08.2013, 22:30:09
Post #6





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


Cytat
W przypadku C/C++ tak, ale w dużej ilości "normalnych" języków standardem jest int-32, long-64. wink.gif

JMSSerializer nie poradził sobie z collection_address OOTB? Bo z obsługą ENUM-a faktycznie trzeba by zapewne robić to ręcznie - przynajmniej częściowo.

W każdym bądź razie, jeżeli pojawią się wersje na inne platformy, będzie to dosyć ciekawa pozycja. wink.gif

Ten post edytował Crozin 30.08.2013, 22:33:23
Go to the top of the page
+Quote Post
wookieb
post 30.08.2013, 22:55:01
Post #7





Grupa: Moderatorzy
Postów: 8 989
Pomógł: 1550
Dołączył: 8.08.2008
Skąd: Słupsk/Gdańsk




Cytat(Crozin @ 30.08.2013, 23:30:09 ) *
W przypadku C/C++ tak, ale w dużej ilości "normalnych" języków standardem jest int-32, long-64. wink.gif

Masz rację - wprowadzę zatem nowe nazwy do wersji 0.2. Dzięki!

Cytat(Crozin @ 30.08.2013, 23:30:09 ) *
JMSSerializer nie poradził sobie z collection_address OOTB? Bo z obsługą ENUM-a faktycznie trzeba by zapewne robić to ręcznie - przynajmniej częściowo.

Może nie "nie poradził" ale nie znalazłem gotowych handlerów do takich rzeczy smile.gif


--------------------
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 29.03.2024 - 05:34