[lib] Konwersja tablic do obiektów i na odwrót, Według schematu danych |
[lib] Konwersja tablic do obiektów i na odwrót, Według schematu danych |
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. -------------------- |
|
|
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? |
|
|
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
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. -------------------- |
|
|
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.
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.
|
|
|
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 |
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
W przypadku Zorro Data Schema nie ma takiego problemu
-------------------- |
|
|
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 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 |
|
|
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 |
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 -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 29.03.2024 - 05:34 |