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.

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?

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.

1. Ale "long long" musiałbyś użyć dopiero przy 128-bitowej liczbie.
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!Mógłbyś pokazać przykład czegoś takiego? Bo chyba nie za bardzo rozumiem co masz na myśli.

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


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



Ż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 

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.

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


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