[lib] Konwersja tablic do obiektów i na odwrót, Według schematu danych Opcje

[wookieb]

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.

[Crozin]

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?

[wookieb]

1) Ciekawa propozycja ale "long long" źle brzmi. Aczkolwiek przemyślę jeszcze raz Twoją propozycje bo jest bardzo ciekawa
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 Choć nie oszukujmy się, że do takich celów jak REST api, JMS/Serializer(Bundle) będzie bardziej przydatny.

[Crozin]

1. Ale "long long" musiałbyś użyć dopiero przy 128-bitowej liczbie.

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!

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.

[wookieb]

1. Ale "long long" musiałbyś użyć dopiero przy 128-bitowej liczbie.

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

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 Będa się tylko różnić plikami opisującymi szczegóły implementacji

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

[PHP] pobierz, plaintext 
// schemat obiektu User zdefiniowany w YAML-u
$serializer = JMS\Serializer\SerializerBuilder::create()
    ->setDebug(true)
    ->addDefaultDeserializationVisitors()
    ->addDefaultSerializationVisitors()
    ->addDefaultHandlers()
    ->addMetadataDir('serializer')
    ->configureHandlers(function (JMS\Serializer\Handler\HandlerRegistry $registry) {
        $registry->registerHandler('deserialization', 'UserStatus', 'json',
            function ($visitor, $obj, array $type) {
                // ręczna tworzenie emulacji ENUM-a
                return 1;
            }
        );
 
        $registry->registerHandler('deserialization', 'collection_address', 'json', function() {
            // ręczne tworzenie kolekcji obiektów Address
        });
    })
 
    ->build();
 
$json = json_encode(array(
    'name' => 'Łukasz',
    'registrationDate' => '2013-08-30T22:47:02+0200',
 
    'status' => 'ACTIVE',
));
$result = $serializer->deserialize($json, 'User', 'json');
[PHP] pobierz, plaintext 

W przypadku Zorro Data Schema nie ma takiego problemu

[PHP] pobierz, plaintext 
// z tablicy na obiekt
$schema->getType('User')->create($data);
 
// z obiektu na tablice
$schema->getType('User')->extract($userObject); // json_encode i gotowe
[PHP] pobierz, plaintext 

[Crozin]

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

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

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.

Ten post edytował Crozin 30.08.2013, 22:33:23

[wookieb]

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

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

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