Z perspektywy czasu, czy oparcie XAML na XML jest błędem czy dobrym podejściem?

XAML jest zasadniczo podzbiorem XML. Mówi się, że jedną z głównych zalet bazowania XAML na XML jest to, że można go sparować z istniejącymi narzędziami. I może, w dużym stopniu, chociaż (atrybuty nietrywialne) wartości atrybutów pozostaną w formie tekstowej i będą wymagały dalszej analizy.

Istnieją dwie główne alternatywy dla opisu GUI w języku pochodnym XML. Jednym z nich jest zrobienie tego, co zrobił WinForms i opisanie tego w prawdziwym kodzie. Jest z tym wiele problemów, choć nie jest to całkowicie pozbawione korzyści ( pytanie, aby porównać XAML z tym podejściem ). Inną ważną alternatywą jest zaprojektowanie całkowicie nowej składni specjalnie dostosowanej do danego zadania. Jest to ogólnie znany jako język specyficzny dla domeny .

Więc, z perspektywy czasu i jako lekcja dla przyszłych pokoleń, czy dobrym pomysłem było oparcie XAML na XML, czy też byłoby lepiej jako niestandardowy język specyficzny dla domeny? Jeśli projektujemy jeszcze lepszą platformę interfejsu użytkownika, czy powinniśmy wybrać XML lub niestandardową DSL?

Ponieważ o wiele łatwiej jest myśleć pozytywnie o status quo, szczególnie takim, które jest bardzo lubiane przez społeczność, podam kilka przykładowych powodów, dla których budowanie na bazie XML może być uważane za błąd.

Oparcie języka na XML wymaga jednej rzeczy: jest o wiele łatwiejsze do parsowania (podstawowy parser jest już dostępny), wymaga znacznie, dużo mniej pracy projektowej, a alternatywne parsery są również znacznie łatwiejsze do pisania dla programistów zewnętrznych.

Ale wynikowy język może być niezadowalający na różne sposoby. To raczej gadatliwe. Jeśli zmienisz rodzaj czegoś, musisz to zmienić w tagu zamykającym. Ma bardzo słabe poparcie dla komentarzy; nie można skomentować atrybutu. Istnieją ograniczenia nałożone na treść atrybutów przez XML. Rozszerzenia znaczników muszą być budowane „na wierzchu” składni XML, a nie głęboko do niej zintegrowane. I, mój ulubiony, jeśli ustawisz coś za pomocą atrybutu, użyjesz zupełnie innej składni niż wtedy, gdy ustawisz dokładnie to samo, co właściwość content.

Mówi się również, że ponieważ każdy zna XML, XAML wymaga mniej nauki. Ściśle mówiąc, jest to prawda, ale nauka składni to niewielki ułamek czasu poświęconego na naukę nowej struktury interfejsu użytkownika; to koncepcje szkieletu sprawiają, że krzywa jest stroma. Poza tym osobliwości języka opartego na XML mogą faktycznie zwiększyć koszyk „wymaga nauki”.

Czy te wady przeważają nad łatwością analizowania? Czy następny fajny framework powinien kontynuować tradycję, czy poświęcić czas na zaprojektowanie niesamowitej DSL, której nie da się przeanalizować za pomocą istniejących narzędzi i której składni wszyscy powinni się nauczyć?

PS Nie wszyscy mylą XAML i WPF , ale niektórzy tak. XAML jest czymś podobnym do XML. WPF to framework z obsługą powiązań, tematów, akceleracji sprzętowej i wielu innych fajnych rzeczy.

language-design xaml Roman Starkov
źródło

Tak, może zostać przeanalizowany przez analizator składni XML, ale nie w sposób znaczący / całkowicie. Na przykład używa atrybutów ciągów do definiowania źródeł danych i odwzorowań właściwości.

Konrad Rudolph

Co proponujesz jako alternatywę? Każda dyskusja na temat przydatności konkretnej technologii musiałaby dotyczyć odpowiednich technologii zastępczych.

Robert Harvey

Wiesz, XAML nie jest pozbawiony odpowiedników. XUL, Glade i QML są oparte na tym samym pomyśle. Myślę, że niesprawiedliwie wyróżniasz XAML.

user16764,

Myślę, że największą zaletą XAML nie jest to, że można go analizować przez parsery XML. Chodzi raczej o to, że XAML jest podobny do XML, a większość programistów już wie, jak pracować z XML, więc krzywa uczenia się jest znacznie mniej stroma.

Juozas Kontvainis

@JuozasKontvainis Jeśli przez „pracę” rozumiesz „parsuj to w swoich narzędziach”, to tak. Jeśli masz na myśli „napisanie opisanego przez niego interfejsu użytkownika”, wówczas znana składnia może wyglądać, jakby to pomogło, ale realistycznie nadal musisz nauczyć się, jak wstawiać atrybuty (ponieważ to nie jest XML), i to jest zdecydowanie najtrudniejsze rzecz, z mojego osobistego doświadczenia. Nauka nowej składni, zwłaszcza jeśli jest prosta i dobrze zaprojektowana, jest moim zdaniem banalna.

Roman Starkov

Odpowiedzi:

Jedynym istotnym powodem używania XML jest ustanowienie standardu otwartych danych. XAML jest tym samym językiem wyświetlania, który jest używany zarówno w Silverlight, jak i WPF; każdy sprzedawca może użyć tego samego standardu znaczników, aby utworzyć definicję wyświetlania dla własnej platformy i można go ponownie wykorzystać w Silverlight lub WPF.

W przemyśle lotniczym mamy pokoje kontrolne, które dzięki postępowi technologii komputerowej są obecnie dość elastyczne. W przeszłości cały sprzęt był niestandardowy, unikalny i bardzo drogi; dziś wszystko działa na niedrogich, powszechnie dostępnych komputerach z półki. To znacznie zmniejsza blokadę dostawcy. Widżety wyświetlania są nadal pisane przy użyciu ActiveX, ponieważ tak zawsze było.

ActiveX wymaga dostępu do przestarzałych narzędzi Microsoft. Air Force i Inter-Range Instrumentation Group opracowują język znaczników wyświetlania danych oparty na języku XML. Umożliwi to praktykom projektowanie ekranów przy użyciu znaczników XML w wybranym przez nich edytorze. Brzmi znajomo?

Nikt nie twierdzi, że XML nie jest pozbawiony wad. Ale to najlepsza dostępna rzecz do tego, do czego została zaprojektowana, dopóki nie pojawi się coś lepszego.

Zobacz także,
dlaczego XML nie jest do kitu

Robert Harvey
źródło

Czy zgodziłbyś się, że to samo rozumowanie stosuje się równie dobrze do takich rzeczy jak, powiedzmy, opisy gramatyczne YACC, TeX, wyrażenia regularne, Verilog, a może nawet LISP? Opracowaliśmy specjalną składnię dla każdego z nich. Korzystałyby z nich w taki sam sposób, jak wymienione w pierwszym akapicie. Czy zatem nie wynika z tego, że użycie XML-a byłoby dla nich właściwe, ponieważ XML spełnia wymienione cele?

Roman Starkov

Tylko XML jest powszechnie uznawany za uniwersalny meta-standard danych, na podstawie którego można utworzyć dowolną liczbę indywidualnych standardów danych. Aby uniknąć zamulenia wód, usunąłem pierwszy akapit.

Robert Harvey

Wyrażenia S nigdy nie zostały uznane za standard metadanych, może dlatego, że nikt nie lubi tych wszystkich głupich nawiasów. Wszechobecność jest tutaj istotnym czynnikiem; wszystkie wymienione przez ciebie alternatywne składnie mogą być reprezentowane w XML, jeśli masz na to ochotę.

Robert Harvey

Wszystkie z nich mogą być reprezentowane również w YAML i JSON (i odwrotnie).

Timwi

Jednym z ogromnych problemów, które widzę w tym argumencie, jest to, że XAML nie jest tak naprawdę danymi. Jasne, może to być po prostu traktowane jako wykres obiektowy, ale tego rodzaju myślenie jest prawdopodobnie powodem, dla którego wielu ludzi go nie lubi i dlaczego ma taką krzywą uczenia się. „hej, chodźmy zrobić wykres obiektowy, mam na myśli interfejs użytkownika”. Nie mam pojęcia, jak można to poprawić, ale jestem pewien, że tak może być.

Earlz

Twoje zastrzeżenia do XML nie mają nic wspólnego z używaniem go jako języka opisu GUI; wszystkie są skargami na pracę ze składnią XML, które dotyczą jednakowo dowolnej formy XML.

Brzmi więc tak, jakbyś po prostu nie lubił XML.

Masz rację, może nie być to optymalny wybór do ręcznej edycji, ale dla języka opisu GUI przedstawiłbym kilka kontrargumentów:

(IMHO,) GUI są graficzne i powinny być ułożone graficznie. Format pliku nie jest tak ważny, ponieważ naprawdę nie powinieneś edytować go ręcznie. (Tekstowe jest dobre dla kontroli źródła, ale gadatliwość nie stanowi problemu).
Oprócz dostępnego analizatora składni XML jest również łatwy do sprawdzenia: można napisać schemat DTD lub XML, a następnie użyć ogólnych narzędzi, aby stwierdzić, czy plik jest legalny. Będzie to bardzo przydatne dla języka opisu GUI. Robienie tego samego w JSON lub YAML nie jest tak proste.
Jeśli naprawdę nie jesteś zadowolony z pisania XAML bezpośrednio, nic nie stoi na przeszkodzie, aby opracować nowy format, a następnie skompilować go do XAML. Na przykład możesz wymyślić proste mapowanie z JSON na XAML, dzięki czemu możesz mieć lżejszą składnię JSON (i możliwość komentowania atrybutów), a następnie wygenerować XAML podczas tworzenia aplikacji. Ludzie rzadko piszą już HTML bezpośrednio, ale HTML jest nadal świetnym formatem.

benzado
źródło

Lubię XML; Po prostu nie lubię pisać ręcznie. 1. Tak, powinny, ale niestety rzeczywistość jest taka, że Visual Studio nie jest w stanie tego zrobić. 3. Jest to ortogonalne wobec dyskusji, czy XAML był z perspektywy czasu złym pomysłem. Tak, można, ale dlaczego trzeba, jeśli XAML nie był złym wyborem?

Roman Starkov,

Chodzi mi o to, że oceniasz go całkowicie na podstawie kryteriów pisania; twoje obawy muszą być zrównoważone z walidacją i interpretacją. DSL, który był ładniejszy do napisania, prawie na pewno trudniejszy do przeanalizowania. Ale pośredni krok kompilacji może dać ci to, co najlepsze z obu światów.

benzado

To pytanie jest subiektywne, więc myślę, że sprawiedliwe jest opublikowanie odpowiedzi opartej na moich osobistych preferencjach.

XML jest trudny do odczytania. Na przykład otwórz ten link i kliknij „Próbka”, aby porównać XML i YAML obok siebie. Ten ostatni jest wyraźnie bardziej czytelny dla człowieka.

Jeśli chcesz użyć XML do opisania GUI, to niech cię cholernie zapewni , że zapewnisz wystarczające narzędzia, aby ludzie nie musieli patrzeć na XML.

Najwyraźniej XPF zawiodło w tym względzie.

John Henckel
źródło