Roman W <b...@g...pl> napisał(a):

> On Tuesday, May 1, 2012 2:54:32 PM UTC+1, Stachu 'Dozzie' K. wrote:
> > Oj, owszem, jest po=BFytek, i to spory. JSON jest niez=B3ym formatem do
> > transportowania danych. Jest du=BFo prostszy od XML-a, zwarty
> > i jednoznaczny. =A3atwiej go r=EAcznie edytowa=E6, produkowa=E6 i przetwa=
> rza=E6
> > ni=BF XML.
>
> W firmie w ktorej pracowalem JSON byl uzywany do przesylania wstepnie
> przetworzonych danych rynkowych z serwera cache do stacji roboczych
> analitykow, wlasnie dlatego ze byl prostszy i szybszy w parsowaniu niz XML.
> Jest tak prosty, ze moglismy go zaladowac dane w formacie JSON do Excela,
> analityk je sobie zmienial jak chcial i wrzucal z powrotem w model
> obliczeniowy. Z XML byloby wiecej rzezby.

Nie kumam o czym piszecie z tą prostotą JSON.
A co z takimi sprawami jak XSD, XSLT, XPath, XQuery?
Przecież takie parsery/transformatory wprawiona osoba
pisze w 3 minuty i ma co chce.
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2012-05-01, M.M. <m...@g...pl> wrote:
> Roman W <b...@g...pl> napisał(a):
>
>> On Tuesday, May 1, 2012 2:54:32 PM UTC+1, Stachu 'Dozzie' K. wrote:
>> > Oj, owszem, jest po=BFytek, i to spory. JSON jest niez=B3ym formatem do
>> > transportowania danych. Jest du=BFo prostszy od XML-a, zwarty
>> > i jednoznaczny. =A3atwiej go r=EAcznie edytowa=E6, produkowa=E6 i przetwa=
>> rza=E6
>> > ni=BF XML.
>>
>> W firmie w ktorej pracowalem JSON byl uzywany do przesylania wstepnie
>> przetworzonych danych rynkowych z serwera cache do stacji roboczych
>> analitykow, wlasnie dlatego ze byl prostszy i szybszy w parsowaniu niz XML.
>> Jest tak prosty, ze moglismy go zaladowac dane w formacie JSON do Excela,
>> analityk je sobie zmienial jak chcial i wrzucal z powrotem w model
>> obliczeniowy. Z XML byloby wiecej rzezby.
>
> Nie kumam o czym piszecie z tą prostotą JSON.
> A co z takimi sprawami jak XSD, XSLT, XPath, XQuery?
> Przecież takie parsery/transformatory wprawiona osoba
> pisze w 3 minuty i ma co chce.

Tylko najpierw trzeba nabrać wprawy, a to długi i kosztowny proces.
W przypadku JSON-a wprawa jest niepotrzebna, that's the point.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Tuesday, May 1, 2012 5:09:42 PM UTC+1, Stachu &#39;Dozzie&#39; K. wrote:
> On 2012-05-01, M.M. <m...@g...pl> wrote:
> > Roman W <b...@g...pl> napisał(a):
> >
> >> On Tuesday, May 1, 2012 2:54:32 PM UTC+1, Stachu 'Dozzie' K. wrote:
> >> > Oj, owszem, jest po=BFytek, i to spory. JSON jest niez=B3ym formatem do
> >> > transportowania danych. Jest du=BFo prostszy od XML-a, zwarty
> >> > i jednoznaczny. =A3atwiej go r=EAcznie edytowa=E6, produkowa=E6 i przetwa=
> >> rza=E6
> >> > ni=BF XML.
> >>
> >> W firmie w ktorej pracowalem JSON byl uzywany do przesylania wstepnie
> >> przetworzonych danych rynkowych z serwera cache do stacji roboczych
> >> analitykow, wlasnie dlatego ze byl prostszy i szybszy w parsowaniu niz XML.
> >> Jest tak prosty, ze moglismy go zaladowac dane w formacie JSON do Excela,
> >> analityk je sobie zmienial jak chcial i wrzucal z powrotem w model
> >> obliczeniowy. Z XML byloby wiecej rzezby.
> >
> > Nie kumam o czym piszecie z tą prostotą JSON.
> > A co z takimi sprawami jak XSD, XSLT, XPath, XQuery?
> > Przecież takie parsery/transformatory wprawiona osoba
> > pisze w 3 minuty i ma co chce.
>
> Tylko najpierw trzeba nabrać wprawy, a to długi i kosztowny proces.
> W przypadku JSON-a wprawa jest niepotrzebna, that's the point.

Idea byla taka, ze dane byly przesylane w trakcie codziennego procesu ktory musial
byc zakonczony w ciagu 2 godzin, albo piszemy listy z przeprosinami do klientow. I w
razie jakiegos problemu, analityk moze wyslac zapytanie z przegladarki do serwera WWW
cache, obejrzec przeslany JSON i podumac czemu dane sa zle. Dlatego prostota byla
kluczowa.

RW

do góry

W dniu 2012-05-01 10:05, Jacek Czerwinski pisze:
> Co do REST, to jest więcej mody, czy twarde argumenty?

Mam wrażenie, że REST i JSON to u ciebie synonimy, a tak nie jest.

> W każdym razie to moje przyszłe dzieło, nie ma nic wspólnego z AJAX-em,
> JS (ani PHP), czy argumenty za JSON dalej są ważne?

JSON zrodził się z konieczności, bo z obsługą XML w web browserze nie
było tak łatwo. W twoim przypadku trzymałbym się SOAP.
IMHO REST jest dobry do budowania smart klientów, a nie wymiany danych
między różnymi, zwłaszcza obcymi, aplikacjami. Masz adres WSDL i
wystarczy - prawie każde IDE odwali za ciebie resztę. Spróbuj tego
samego w REST. Jak sobie zażyczysz dwufazowego commita, to też tylko SOAP.

artur

do góry

W dniu 2012-05-01 12:57, Jacek Czerwinski pisze:
[...]
> Pytanie: jakie są dobre biblioteki JSON do C#, Javy i C++.

Zależy, co rozumiesz przez "dobre"? Z naszych poszukiwań w ramach C/C++
dobry okazał się yajl, bo łatwo w nim było obsługiwać duże obiekty
przychodzące z sieci w porcjach - łatwo trzymać stan przetwarzania
i nie wymaga całego obiektu na raz. Z kolei do generowania JSONa
naskrobałem własnego writera, bo ze względu na wydajność przetwarzanie
własnej struktury na drzewo obiektów biblioteki i potem serializacja
była nieefektywna.

--
Paweł Kierski
n...@p...net

do góry

On Tuesday, May 1, 2012 11:57:08 AM UTC+1, Jacek Czerwinski wrote:

> Pytanie: jakie są dobre biblioteki JSON do C#, Javy i C++.

W projekcie w ktorym pracowalem uzywalismy json-lib (Java).

RW

do góry

> Co do REST, to jest więcej mody, czy twarde argumenty? Ja to postrzegam w
> postaci dalekiej analogii pomiędzy językami kompilowanymi a skryptowymi,
> bardziej podatne do zrobienia 'na kolanie'. Dobrze myślę? Czego nie wiem?

Jak już kolega wcześniej napisał idea REST to filozofia czterech operacji
CRUD wykonywanych na trwałym bycie określonym poprzez URL. Przekłada to
środek ciężkości logiki biznesowej na klienta. Usługa REST jest bardziej
repozytorium danych niż serwisem biznesowym. Json jest zaś bliższy temu o
czym piszesz - luźny, "skryptowy" opis danych, możliwy do błyskawicznego
wczytania przez javascriptowy eval(), bez kosztownego czasowo parsowania.

do góry

W dniu 2012-05-07 07:28, William Bonawentura pisze:
>
>
>> Co do REST, to jest więcej mody, czy twarde argumenty? Ja to
>> postrzegam w postaci dalekiej analogii pomiędzy językami kompilowanymi
>> a skryptowymi, bardziej podatne do zrobienia 'na kolanie'. Dobrze
>> myślę? Czego nie wiem?
>
> Jak już kolega wcześniej napisał idea REST to filozofia czterech
> operacji CRUD wykonywanych na trwałym bycie określonym poprzez URL.

Jasne. Dla mnie "świeże" w tym pomyśle jest intensywne wykorzystanie
cech HTTP (4 polecenia http wprost zastosowane) i pewnie (?) kody
powrotu, spotkałem to w opisie którejś z bibliotek (nie wiem czy jest to
powszechne).
(Podobnie jak kilka implementacji ma koncepcje pojedynczego wyniku i
kolekcji, też nie wiem czy to "przenośne" skoro nie jest to mocno objęte
standardami ...)

Jak kilka razy się robiło "ręcznie" (na różnych dziwnych
architekturach), łatwo się odnaleźć.

do góry

W dniu 2012-05-07 07:28, William Bonawentura pisze:
> Json [...]możliwy do
> błyskawicznego wczytania przez javascriptowy eval(), bez kosztownego
> czasowo parsowania.

Eval jest passe. :-)
Wspolczesne przegladarki maja wbudowana metode JSON.parse(), dla staroci
pozostaje np. jQuery.parseJSON()

--
NotBear

do góry

W dniu 2012-05-01 12:57, Jacek Czerwinski pisze:

> Akurat językowo pozostając poza JavaScriptem nie na specjalnie z tego
> JSON pożytku, ale pewnie programiście który integrował się z portalami
> jest to znajome. Pewnie, skoro najwięksi to robią, są jakieś sprawdzone
> biblioteki...

Pożytki z JSON:
- z powodzeniem zastępuje xml w zadaniu przekazywania struktur danych, a
jest znacznie 'lżejszy'.
- naturalny do dogadywania się z JavaScriptem, co ma znaczenie

I tyle ...

do góry