Obiektowe podejście do tworzenia stron internetowych znalazło kolejnego sprzymierzeńca w postaci organizacji W3C. Wczoraj object oriented CSS, dziś object oriented HTML! Nowa, obiektowa wersja języka HTML (zupełnie niezależna od powstającego HTML 5) ma zastąpić XHTML, który nie zdobył zbyt dużego uznania wśród developerów. Tzw. release candidate ujrzy światło dzienne latem bieżącego roku.
Wielu twórców stron internetowych narzekało na brak skalowalności i toporne zasady dobierania określonych znaczników. Powtarzano jak mantrę, że HTML nie ma nic wspólnego z programowaniem. Nie było dotąd żadnej możliwości użycia wzorców projektowych, raził brak kompilatora, a częste wycieki pamięci (tzw. memory leaks) w Internet Explorer coraz głośniej przypominały o potrzebie zastosowania Garbage Collectora. W3C, dotąd głuche na nawoływania zirytowanych programistów, postanowiło wyjść naprzeciw tym, którzy chcieliby tworzyć semantyczne i dobre strony internetowe. Jak udowodniła ostatnia ankieta na znanym blogu Techcrunch, dla większości badanych (ponad 70% respondentów opowiedziało się za tą opcją!) HTML jest zbyt zawiły (spójrzmy – przecież to zupełnie inne podejście do programowania!) i niezgodny ze współczesnymi dogmatami programowania.
Świat się zmienia — nie ukrywajmy tego. Developerzy stali się o wiele bardziej wymagający, chcą narzędzia odpowiadającego ich sporym umiejętnościom. W dobie OOCSS i innych obiektowych narzędzi, przestaliśmy być bierni wobec postępującego zjawiska obiektowości. Zaangażowaliśmy do badań swoich najlepszych specjalistów już 3 lata temu. Dziś z dumą ujawniamy rezultaty ich pracy.
Czym zaskoczy OOHTML?
Zmieni się przede wszystkim struktura dokumentów. Każda strona HTML będzie odzwierciedleniem klasy, którą trzeba będzie zdefiniować już na początku:
<class>news</class>Domyślnie klasa w HTML będzie posiadała publiczny specyfikator dostępu. Nic nie szkodzi jednak na przeszkodzie, by wzbogacić ją o private czy protected.
<privateclass>news</privateclass>W tym wypadku, prywatna klasa spowoduje, że kod źródłowy będzie niedostępny dla podglądu. Koniec ze skryptami blokującymi prawy przycisk myszy i dostęp do „Pokaż źródło strony!”. Wreszcie developerzy nie będą oceniani za jakość kodu, a za jego efektywność.
Z kolei klasa protected:
<protectedclass>news</protectedclass>będzie zachowywać się tak, jak klasa publiczna, lecz dzięki magicznemu słowu protected zwiększą się zabezpieczenia przed wszelakimi intruzami, wirusami i trojanami. Jest to swoisty precedens, ponieważ W3C pierwszy raz bierze na swoje barki odpowiedzialność za bezpieczeństwo przeglądania stron, odciążając tym samym producentów przeglądarek. Rozwiązanie jest szeroko dyskutowane wśród banków, którym jak nikomu innemu zależy na bezpieczeństwie.
Warto dodać, że plik OOHTML powinien nazywać się tak, jak klasa w nim zdefiniowana, niezależnie od modyfikatora dostępu. Możemy również zapomnieć o tagu <html />!
Interfejsy
Co więcej, zyskamy dostęp do interfejsów, które będą zapisywane w pliku z rozszerzeniem .ihtml. Przykładowy interfejs:
<interface name="ExampleInterface">
<div>
<h1></h1>
<p></p>
</div>
</interface>Klasa interpretująca dany interfejs powinna wyglądać następująco:
<class implements="ExampleInterface">index</class>
<head></head>
<body>
<div>
<h1></h1>
<p></p>
</div>
</body>
O ile w interfejsie nie możemy zdefiniować implementacji danych tagów (np. atrybutów typu class, id, href itd.), tak w implementującej go klasie da się zrobić cokolwiek:
<class implements="ExampleInterface">index</class>
<head></head>
<body>
<div id="article">
<h1><a href="#"></a></h1>
<p class="content"></p>
</div>
</body>Dziedziczenie
W OOHTML zaimplementowano również dziedziczenie:
<class extends="ParentClass">index</class>W ten sposób strona odziedziczy wszystkie tagi w <body> z pliku ParentClass.html. Co więcej, nadchodzi wielkie ułatwienie dla twórców startupów i pochodnych! Otóż, będzie można dziedziczyć także od konkretnych adresów URL:
<class extends="http://digg.com">index</class>Jestem pewien, że twórcy wykopu, blipa i innych inspirowanych serwisów skorzystaliby właśnie z tej opcji. Z całą pewnością jest to rozwiązanie o wiele tańsze i wygodniejsze niż pisanie kodu od nowa. W3C myśli również nad gotowymi template’ami do dziedziczenia. I tak, możliwe będzie odziedziczenie z szablonu web2.0:
<class extends="web2.0"></class>Wygeneruje to następujący kod w <body>:
<div id="logo"></div>
<div id="friends"></div>
<div id="tags-cloud"></div>
<div id="javascript-disabled"></div>
<div id="add2digg"></div>
<div id="add2delicio"></div>
<div id="add2whatever"></div>Poliformizm
Poliformizm? Jasne! W zależności od kraju, skąd pochodzi dany user, strona będzie tłumaczona na lokalny język. Wystarczy zdefiniować obsługiwane kraje:
<class polymorphism ="pl,en,it">index</class>Zapomnijmy o tłumaczach i ciężkiej pracy po stronie back-endu. Nadchodzi OOHTML z poliformizmem, jakiego jeszcze świat nie widział.
To na razie wszystko, co zdążyli ujawnić twórcy OOHTML, jeśli chodzi o składnię. Jak mówi Bill Jobs, jeden z głównych ewangelistów w W3C, sprawa jest jeszcze otwarta:
Postaramy się dogodzić każdemu programiście — tym, którzy programowali w C++ i tym, którzy mieli styczność na przykład z Delphi czy Basiciem. Nasz zespół stale prowadzi badania nad współczesnymi, obiektowymi językami programowania. Chcemy wyciągnąć z nich to, co najlepsze. Na pewno więc zajdą pewne rozbieżności pomiędzy obecnym, a oficjalnym API. Poza tym, mamy kilka asów w rękawie, których wolimy jeszcze nie ujawniać (śmiech).
HTML Garbage Collector
Oprócz tego, W3C informuje o dodatkowych cechach języka, niezwiązanych ze składnią. I tak, dostaniemy HTML Garbage Collector, który będzie odśmiecał z pamięci niepotrzebne dane. Zapowiada się duży wzrost szybkości, jeśli chodzi o aplikacje napisane w AJAX! Poza tym, koniec z memory leaks w Internet Explorer — wszystko, co wycieknie poza przeglądarkę zostanie wyłapane przez odśmiecacz i z powrotem ulokowane w pamięci. Czy potrzebna będzie maszyna wirtualna lub cokolwiek w tym stylu? Twórcy zapowiadają, że nie:
Rozmawialiśmy z producentami najpopularniejszych przeglądarek. Wszystkie zgodziły się na zaimplementowanie naszego Garbage Collectora. Nadal jednak prowadzimy rozmowy z Mozillą, która twierdzi, że pracuje już od dawna nad podobnym rozwiązaniem.
Na wieść o OOHTML szybko zareagowali również developerzy Eclipse. Mamy informację, że powstanie specjalne rozszerzenie do programu — OOHTML Eclipse. Zapowiada się rewolucyjnie – pierwsza w pełni obiektowa wersja języka z gotowym i sprawdzonym IDE!
Przy okazji informacji o OOHTML, zostały rozwiane wątpliwości co do kompatybilności wstecznej w Internet Explorer. Jego twórcy sensacyjnie przyznali, że IE obsługuje w pełni wszystkie cechy obiektowego HTML. Powołując się na Internet Explorer blog:
Był taki moment, kiedy w 2000 roku myśleliśmy, jak zrewolucjonizować programowanie stron internetowych w HTML. Jedną z opcji był właśnie OOHTML. Co zdumiewające, nasze założenia były wręcz identyczne, jak te z W3C. Zaczęliśmy więc implementację w kontekście IE6. Był chyba luty. Niestety, w tym czasie zmieniali się ludzie w dziale marketingu. Wiesz, reorganizacja. Nowy szef, John Doe stwierdził, że OOHTML to zbyt duża rewolucja, która może obrócić się na naszą niekorzyść. Fakt — OOHTML ma mnóstwo zastosowań, ale jest o wiele trudniejszy w nauce dla typowego Kowalskiego. Zaprzestaliśmy więc prac, jednak dotychczasowa implementacja OOHTML pozostała w silniku IE (Trident). Paradoksalnie wystarczy jedna zmiana w pliku config.dll, by włączyć tę fascynującą opcję, jaką wydaje się być OOHTML!
Zapowiada się duży przełom. Z niecierpliwością czekam na nowe informacje o OOHTML. Naprawmy wreszcie tą spróchniałą sieć!
Komentarze
i znowu trzeba się będzie uczyć wszystkiego od poczatku :( masakra :/
A ja sie nie dam nabrac :)
spoiler! dałbym Ci minusa, jakby się dało.
Rzeczywiście w Tridencie te funkcje są dostępne, ale zablokowane. Ale switch, o którym piszą na IE blogu, jest możliwy do przełączenia po dekompilacji silnika i funkcje można wykorzystywać (są wersje standalone z odblokowaną wersją silnika — podrzucę linka jeśli odkopię).
Niestety, jak zwykle pozostali producenci przeglądarek pozostali w tyle (nie dziwi fakt, że Mozilla musi forsować własne rozwiązania) i kolejny raz trzeba latami czekać na używanie niesłychanie wygodnych i przydatnych funkcji.
NIe ma co, brawa za kreatywność ;p Koncowka z ukrytym modulem w IE FTW :d
Wyrafinowane! :)
Ale zaraz, skoro do OOCSS podchodziłes jakoś niezbyt entuzjastycznie, to skąd taki zachwyt OOHTML? I czemu kod bloga do niego nie przepisany tak na eksperyment? :>
To gorace info, jeszcze nie do konca wiem, jak w JSie wlaczyc kompatybilnosc w IE o ktorej wspomnial bober. OOCSS to byly natomiast tylko przymiarki do czegos o wiele wiekszego, jakim jest OOHTML. Od poczatku uwazalem, ze to jeszcze nie koniec i zostaniemy czyms zaskoczeni, wiec wolalem byc sceptyczny wobec OOCSS.
nieźle ;) Nie wpadłbym na taki pomysł na żart prima-aprilisowy ;)
Jestem pod wrażeniem wykonania pomysłu tego żartu. :) Naprawdę w na początku uwierzyłem. Gratuluję. ;)
Rzeczywiście żart wielkiego formatu. Trudno uwierzyć, że W3C weźmie odpowiedzialność za tyle elementów, a jeszcze dziwniejsza jest zgodność producentów przeglądarek na takie rewolucyjne zmiany.
Dzieki ;-)
Na początku dałem się nabrać, ale kiedy przeczytałem info o IE, od razu przewinąłem na górę żeby sprawdzić datę publikacji – niezły żart ;)