Delphi bliżej Linuxa

Inprise/Borland zaprezentowała stan prac nad specjalną wersją Delphi, przeznaczoną dla systemu operacyjnego Linux. Na razie nie wiadomo, kiedy pojawi się pierwsza wersja beta.

Inprise/Borland zaprezentowała stan prac nad specjalną wersją Delphi, przeznaczoną dla systemu operacyjnego Linux. Na razie nie wiadomo, kiedy pojawi się pierwsza wersja beta.

Wiadomo że środowisko programistyczne, określane wstępnie CLX lub Kylix, ma być niemal w 100% zgodne z Delphi 6.0. Duży nacisk położono na zachowanie jak najdalej idącej kompatybilności na poziomie komponentów zawartych w narzędziu RAD, by można było bezproblemowo przenosić warstwę podstawowego interfejsu graficznego i mechanizmów związanych z konstruowaniem logiki bizne-sowej aplikacji. Według przedstawi- cieli Inprise/Borland, prezentujących stan prac nad CLX podczas odbywającej się w ubiegłym tygodniu w Warszawie konferencji Borland Developer Days, język Object Pascal ma być dokładnie taki sam dla Linuxa, jak dla Windows.

Podstawy GUI

CLX jest oparty na bibliotece QT, spec-jalnym interfejsie C++, pozwalającym na pisanie kodu w C++, obsługującego GUI X Windows. QT jest rozwiązaniem bezpłatnym, ale tylko dla projektów typu Open Source. Wraz z licencją CLX programista otrzyma licencję na korzystanie z QT w aplikacjach komercyjnych.

Duża część bibliotek CLX to w rzeczywistości wrappery, obudowujące wywołania odpowiednich elementów QT, tak by były dostępne z poziomu Object Pascal. Część elementów z Windows nie będzie mogła być przeniesiona na poziom X Windows i QT.

Podstawowy problem przy przenoszeniu między Win32 API a QT jest związany z tym, że QT ukrywa kolejkę komunikatów przed programistą. Tak naprawdę opiera się na wymianie sygnałów pomiędzy powiązanymi elementami (SLOT/SIGNAL). Nie będzie więc można skorzystać z mechanizmu subclassing w Win32 (aplikacja przechwytuje komunikat przekazywany do konkretnego elementu GUI i wykonuje dodatkowe operacje) czy kontrolki owner draw. W CLX wprowadzono style, które w pewnym stopniu pozwalają zastąpić mechanizm owner draw. Nie wiadomo natomiast, czy w CLX pojawią się mechanizmy zastępujące przechwytywanie komunikatów. Jak zapewniają przedstawiciele Inprise/ Borland, prawdopodobnie powiązania między poszczególnymi elementami interfejsu będą tworzone dynamicznie - będą mogły zmieniać się podczas działania aplikacji. Znaczna część interfejsu użytkownika tworzona w Delphi opierała się na własnych kontrolkach VCL. Warto podkreślić, że w QT można także tworzyć własne elementy interfejsu graficznego (tu nazywane widgets). Taki nowy element może być bez problemów wykorzystywany z poziomu CLX, jeśli zostanie napisany do niego dodatkowo wrapper. Oczywiście, będzie także możliwe tworzenie komponentów w CLX.

Co będzie, czego zabraknie

W CLX na pewno nie będzie mechanizmu pozwalającego dokować okna, obsługiwać wiele języków (zwłaszcza azjatyckich; nie będą przenoszone standardy BiDi czy IME). Zniknie także większość elementów związanych z obsługą COM, a zwłaszcza interfejsem IDispatch. Przedstawiciele Inprise/Borland na razie nie potrafią odpowiedzieć, czy zostanie wprowadzony mechanizm późnego wiązania, pozwalający, by interfejs wywołanego obiektu określany był dopiero podczas działania aplikacji.

Komponenty związane z obsługą komunikacji czy XML będą miały takie same właściwości i metody w Windows i Linuxie. Aplikacje, korzystające z gniazdek (sockets) będą mogły być kompilowane na obu platformach, bez zmiany jednej linii kodu. Także komponenty Internet Express i mechanizmy WebBroker (służące m.in. do tworzenia dynamicznego HTML) będą dostępne na obu platformach z takim samym zestawem usług. W przypadku WebBrokera, komponenty będą obsługiwać dowolne serwery WWW z tym, że mają zawierać pewne mechanizmy dostosowane specjalnie do serwera Apache (na Windows i Linuxa).

CLX i bazy danych

Rewolucyjne zmiany zostaną wprowadzone w obsłudze baz danych. Nie zmienią się podstawowe mechanizmy dostępu, jednak architektura aplikacji bazodanowej tworzona przy użyciu CLX będzie korzystać z usług warstwy pośredniej MIDAS. Inprise opracowuje przenośną warstwę dostępu do bazy danych (SQLExpress), na której będzie się opierać nowa architektura.

Programista będzie miał do dyspozycji 5 głównych obiektów: SQLDriver - interfejs, który musi implemento- wać sterownik do bazy danych, SQLConnection odpowiadający za połączenie z bazą, pośrednik SQLCommand, który pozwala wykonywać procedury przechowywane po stronie serwera bazodanowego i kwerendy zdefiniowane w kodzie programu, oraz SQLCursor służący do poruszania się po zbiorze rekordów. Ponadto jest zapowiadany SQLMetadata, który będzie specjalnym interfejsem pozwalającym na implementację przez SQLDriver niestandardowych cech motoru bazy danych. Warto podkreślić, że nie będzie obiektu TTable!

Za przechowywanie rekordów po stronie klienta odpowiada TClientDataSet, podobnie jak w obecnej wersji Delphi. Dane są przekazywane ze sterownika do warstwy MIDAS, a dopiero potem do aplikacji, tak więc wszystkie otwierane po stronie serwera bazodanowego są typu forward only. Za poruszanie się po zbiorze rekordów odpowiada MIDAS. Równocześnie, dzięki wykorzystaniu warstwy pośredniej zniknęły wszystkie mechanizmy związane z tzw. wsadową aktualizacją bazy danych (batch updating).

Planując nową architekturę dostępu do danych, inżynierowie Inprise postanowili, że w żadnej sytuacji warstwa danych nie będzie sama tworzyć zapytań SQL np. by uaktualnić dane w tabeli. Programista będzie miał kontrolę nad każdym aspektem komunikacji z bazami danych.

Inne zmiany

W CLX nie będzie interfejsu BDE. Prawdopodobnie nie będzie też wizualnych narzędzi do konstrukcji wyrażeń SQL. Programiści nie będą mogli skorzystać też z Decision Cube ani Data Dictionary. W opracowywanej obecnie wersji CLX zabraknie też komponentu QuickReport, czyli bardzo wygodnego narzędzia do tworzenia raportów. Wszystkie raporty w aplikacji przenoszonej na Linuxa trzeba będzie tworzyć od początku. CLX prawdopodobnie będzie zawierał zupełnie inny mechanizm do przygotowywania raportów.

Trudno już dziś określić spowolnienie prędkości działania i wzrost wielkości pliku wykonywalnego w Delphi w porównaniu z interfejsem graficznym pisanym w czystym QT i C++. Wiadomo że taki "narzut" będzie istniał, chociażby z powodu wykorzystania wrapperów.

Mimo że nie uda się przenieść na Linuxa wszystkich mechanizmów właś-ciwych dla Windows, to CLX będzie ciekawą propozycją. Stanie się moż- liwe przeniesienie istniejących aplikacji Delphi. Jeśli programista zdecy- duje się na wykorzystywanie tylko standardowego interfejsu użytkow- nika, może tworzyć aplikacje, które będą kompilowały się zarówno w Delphi 6.0, jak i CLX.


TOP 200