coder's life

W programowaniu często jest tak, że zrobienie podstawowej rzeczy jest proste i szybkie, dotyczy to w szczególności frameworków. W dystrybucji danej biblioteki mamy często mnóstwo przykładów, które charakteryzują się jednym elementem - są proste, niekiedy zbyt proste. Podobnie zresztą jest z większością tutoriali. Jednak czy jest to problem. Na początku nie, ale później owszem. Bo co z tego, że po zapoznaniu się z przykładami, czy kursami potrafimy zrobić jeden formularz skoro nie wiemy jak zaprojektować, a później zaprogramować całą aplikację. Oczywiście intuicja podpowiada programiście, w którym kierunku należy podążać, jednak zawsze zadaje sobie on pytanie czy jest to kierunek słuszny, zgodny ze sztuką i czy architektura jego aplikacji jest optymalna. Właśnie na taki problem napotkałem tworząc aplikację w GWT. Moja aplikacja składać się miała z dwóch elementów: panelu dla użytkownika oraz panelu dla administratora. Jednak pewne elementy tych paneli miały być wspólne: zarówno element

Zacznę od przedstawienia problemu, który oczywiście nie istnieje dopóki się go nie napotka :) Problem tkwi w tym, iż część parserów XML zamyka wejściowy strumień ( InputStream ) kiedy napotka EOF (-1). Dotyczy to choćby Xercesa, który jest domyślnym parserem dla biblioteki JDOM. Oczywiście nie byłoby w tym nic złego gdyby wejściowym strumieniem nie był SocketInputStream , ponieważ jego zamknięcie powoduje jeden niekoniecznie pożądany skutek, a mianowicie zamknięcie socketu, który w efekcie jest już bezużyteczny co oznacza nic innego jak to, iż nie można przez niego wysłać odpowiedzi. W przypadku dużej części aplikacji sockety są wykorzystywane do realizacji klasycznego modelu żądanie-odpowiedź np. klient wysyła do serwera dokument XML, serwer go przetwarza, a następnie odpowiada klientowi innym dokumentem XML. Jednak w przypadku gdy po wczytaniu dokumentu XML przez serwer socket zostanie zamknięty, klientowi nie zostanie udzielona odpowiedź. Co można w takim razie zrobić aby osiągnąć

Komu się nie zdarzyło czegoś skrobnąć w Swingu i/lub Delphi z wykorzystaniem graficznego designera, pewnie większości programistów. Owszem może kod który powstaje dzięki takiemu narzędziu nie jest najwyższych lotów, ale przynajmniej taki interfejs graficzny tworzy się po prostu szybko, nawet nie będąc ekspertem w zakresie danej biblioteki, koncentrujemy się tylko nad obsługą poszczególnych zdarzeń (np. onClick itd). No tak ale co z tego jak dzisiaj każdy (no może prawie każdy) oczekuje, że aplikacja będzie dostępna przez przeglądarkę Internetową i oczywiście aplety odpadają bo trzeba instalować JRE itd. Pamiętam historię, którą opowiedział mi mój znajomy o firmie w której programiści kilka lat temu tworzyli aplikację w Visual Basicu, a teraz robią to w JSP. Zapytałem czy są zadowoleni, a on odpowiedział, że nie do końca, ponieważ nie potrafią zrozumieć dlaczego, coś co tworzyli przez jeden dzień zajmuje im teraz trzy dni... Ta krótka opowieść zalatuję nostalgią za korzeniami, za środow

Google udostępniło programistom Google Web Toolkit (GWT), framework do szybkiego i przyjemnego tworzenia aplikacji webowych. Oczywiście słowo "przyjemnego" jest kwestią względną, ale na pewno tak mógłby powiedzieć programista Java, który stroni od JavaScriptu i HTMLa. Dlaczego? Bo w GWT nie musi stosować żadnego innego języka poza Javą. Ale czy to jest właśnie kierunek rozwoju frameworków webowych, który okaże się tym najwłaściwszym. W tym momencie ciężko przesądzić. Zupełnie inną koncepcję proponuje Yahoo - tak, tak Yahoo też postanowiło wystawić swojego zawodnika :) Nazywa się on The Yahoo! User Interface (YUI). Biblioteka ta jest zbiorem narzędzi i kontrolek napisanych w JavaScripcie, do budowania interaktywnych aplikacji webowych. Opiera się w dużej mierze na operowaniu na DOMie, DHTMLu i AJAXie. Wszytkie komponenty dostarczane przez Yahoo są open sourcowe na licencji BSD i można ich używać do woli. W celu zaprezentowania podstawowych możliwości Yahoo posłuże się prosty

Od czasu kiedy pojawiło się GWT minęło już sporo czasu, dlatego można go już oceniać nie tylko pod kątem tego czy zaproponowana przez Google koncepcja jest właśnie tą na którą czekają programiści webowi, którym dzierganie w JavaScriptcie po prostu nie odpowiada, ale również można oceniać go pod kątem popularności jaką zdobywa i przyznam, że przeglądając zasoby Internetu wyraźnie widać, że pozostawia konkurencję w tyle jak choćby framework YUI tworzony przez Yahoo. Innym istotnym elementem, który wpływa w zasadniczy sposób na popularność danego frameworku jest wsparcie jakie zyskuje on w środowisku OpenSource'owym, głównie mam tutaj na myśli ilość darmowych rozszerzeń jaka jest tworzona przez to grono programistów. Wczoraj przeszukując Internet natrafiłem na bardzo ciekawą bibliotekę gwt-dnd , która przy naprawdę niewielkim nakładzie pracy pozwoli na zbudowanie interfejsu użytkownika z elementami Drag&Drop . Podstawową zaletą tej biblioteki jest to, iż możemy korzystać ze sta

Ostatnio zainteresowałem się nieco poważniej tematyką portali - po zapoznaniu się z kilkoma darmowymi rozwiązaniami zdecydowałem, że w dalszej wędrówce będę korzystał z Liferaya ze względu na jego stabilność, dojrzałość i duże możliwości oraz zgodność z JSR 168. Ze względu na to, iż jestem programistą głównie moją uwagę skupiłem na pisaniu portletów, a że JSP i Servlety są bardzo bliskie mej duszy, pisanie ich nie stanowiło dla mnie najmniejszego problemu - okazało się zajęciem miłym, łatwym i przyjemnym, do czasu... Właśnie do czasu kiedy uznałem, że warto by skorzystać z jakiegoś frameworku (nawet więcej - środowiska deweloperskiego), jednak takiego w którym byłoby dużo komponentów na dość wysokim poziomie abstrakcji, graficzne środowisko deweloperskie do projektowania stron WWW np. tak jak w Sun Java Studio Creator 2 . (Przypomnę, że narzędzie to posiada graficzny edytor do budowania stron JSF.) Zanim do tego przystąpiłem zapoznałem sie nieco dokładniej ze specyfikacją JSR 168 . Sz