środa, 14 września 2011

Windows 8 pre-beta



       Microsoft udostępnił wersję pre-beta (Windows Developer Preview) systemu operacyjnego Windows 8.Udostępniona wersja Windows 8 została określona przez Microsoft jako Windows Developer Preview. Oznacza to, że jest to wczesna wersja testowa, nie przeznaczona do codziennego użytkowania. Firma ostrzega, że system może działać niestabilnie. Użytkownicy mogą pobrać obraz płyty instalacyjnej (ISO) w jednym z trzech wariantów - wersja 64-bitowa, wersja 64-bitowa wraz z pakietem narzędzi programistycznych lub wersja 32-bitowa.
Microsoft podał minimalne wymagania sprzętowe systemu Windows 8 pre-beta. Do uruchomienia następcy Windows 7 wystarczy komputer z procesorem 1 GHz, 1 GB pamięci RAM (2 GB dla wersji 64-bit), układem graficznym zgodnym z DirectX 9 i 16 GB wolnego miejsca na dysku. W praktyce oznacza to, że Windows 8 pre-beta powinien bez problemu działać nawet na starszych, kilkuletnich maszynach. Firma ostrzega, że nie ma możliwości odinstalowania Windows 8 pre-beta - by przywrócić poprzedni system operacyjny, należy skorzystać z oryginalnego nośnika instalacyjnego lub utworzonej wcześniej kopii bezpieczeństwa. Oczywiście istnieje także możliwość wykonania czystej instalacji, która nie powinna naruszyć obecnego systemu operacyjnego.
Obraz płyty instalacyjnej Windows 8 pre-beta (Windows Developer Preview) można pobrać bezpośrednio ze strony Windows Dev Center.

      Oto film pokazujący instalację systemu na wirtualnej maszynie VirtualBox:




Tutaj zaś ciekawy film prezentujący szybkość ładowania się systemu na komputerze z tradycyjnym dyskiem mechanicznym.




Dla osób mających problem z instalacją Windows 8 na VirtualBox pre-beta polecam link :
http://www.sysprobs.com/guide-install-windows-8-virtualbox
źródło: dobreprogramy.pl

JAVA EE6 Programowanie aplikacji WWW KURS cz. 8 Wprowadzenie do JSP

     


      JSP - JavaServer Pages jest to technologia, która umożliwia zagnieżdżenie kodu Java w dokumentach HTML. Wcześniej skupialiśmy swoją uwagę na mechanizmie działania serwletów. Generowanie kodu HTML z wykorzystaniem metody println() obiektu PrintWriter. Takie podejście bardzo komplikuje kod i utrudnia korzystanie z narzędzi do tworzenia dokumentów HTML. Podział pracy między tworzeniem wizualnej strony, a tworzeniem logiki jest zachwiany. Odpowiedzią na powyższą wadę serwletów było opracowanie przez firmę Sun technologii JavaServer Pages.



      JSP pozwala nam na wstawianie do zwykłego kodu HTML konstrukcji w języku Java - co nie jest obecnie zalecane. Umieszczanie kodu Java w dokumencie HTML odbywa się z wykorzystaniem specjalnych znaczników.




      Takie umieszczenie konstrukcji językowych Java w dokumencie JSP nazywamy skryptami. Nie powinniśmy stosować takiego rozwiązania, ponieważ jak wiemy JSP zostało stworzone w celu uniknięcia niewygodnego generowania stron HTML z wykorzystaniem serwletów, a także do rozdzielenia mechanizmów aplikacji webowej czyli warstwy logiki aplikacji od warstwy prezentacji. Skryplety burzą ten podział. Powiedzmy sobie po prostu, że jest to przeszłość. Zamiast nich powinniśmy używać specjalnych znaczników EL i JSTL. Wspomniałem kiedyś, że JSP to tak naprawdę serwlet. Od strony technicznej dokument JSP przy pierwszym uruchomieniu jest przekształcany na serwerze do odpowiadającego im serwletu.




       
       Klient wysyła żądanie pobrania strony, które po przejściu przez serwer HTTP trafia do serwera aplikacji - Web server. Żądanie zostaje przekierowane do kontenera JSP, który znajduje się na serwerze aplikacji. Podczas pierwszego żądania pobrania strony JSP zostaje ona wysłana do translatora JSP. Translator generuje kod wynikowy w postaci klasy serwletu. Kod źródłowy jest przesyłany do kompilatora Java, gdzie zamieniamy jest na Java Byte Code maszyny wirtualnej. Od tej pory ten skompilowany kod czyli tak naprawdę serwlet jest zarządzany przez kontener serwletów.
Skompilowane strony JSP pozostają załadowane do maszyny wirtualnej Java i kolejne odwołania do tej samej strony nie wymagają przejścia przez fazę translacji.



      Obecnie technologia JSP ma wsparcie w postaci języka wyrażeń EL- Expression Language i standardowej biblioteki znaczników JSTL - JavaServer Pages Tag Library.EL i JSTL zastępują nam znaczniki, które za bardzo komplikują kod, a także mieszają logikę prezentacji i aplikacji.

Strony JSP mogą odwoływać się do obiektów predefiniowanych w skryptach :
  • request - wszystkie parametry wywołania strony JSP (HttpServletRequest)
  • response - reprezentuje odpowiedź zwracaną klientowi (HttpServletResponse)
  • out - reprezentuje stronę zwracaną klientowi (jsp.JspWriter)
  • session - reprezentuje sesję HTTP (http.HttpSession)
  • application - reprezentuje kontekst aplikacji (ServletContex)
  • config - konfiguracja serwletu (servletConfig)
  • pageContext - obiekty, które są w zasięgu widoczności bieżącej strony (jsp.PageContext)
  • page - reprezentuje bieżącą stronę (java.lang.Object)


      Przyjrzyjmy się skryptom JSP, których jak już wspomniałem nie należy używać. Skrypty są to :

  • <%= wyrazenie  %> - wyrażenia są one przekazywane na wyjście czyli okno przeglądarki
  • <% kod %> - skryplety są umieszczane wewnątrz metody service() serwletu
  • <%! kod %> - deklaracje są umieszczane wewnątrz klasy serwletu poza metodami
      Przykład wyrażenia: Przykład skrypletu: Przykład deklaracji:       JSP dostarcza dyrektyw czyli kilku różnych konstrukcji stosowanych w zależności od danej sytuacji. Istnieją ogólnie trzy główne typy dyrektyw:
  • page - pozwala m.in. na importowanie klasy, określić język użyty w skryplecie itp.
  • include - pozwala na dołączenie innego pliku do treści danej strony
  • taglib - jest związana z technologią JSTL, której przyjrzymy się później po omówienie EL


      Przykład dyrektywy page:




      Jak widzimy dyrektywa taka posiada pewne atrybutu, nie są to wszystkie atrybuty jakie może przyjąć.

      Oto najważniejsze ustawienia dyrektywy page:
  • contentType - określa typ MIME strony np. text/html
  • pageEncoding - kodowanie znaków na stronie
  • isErrorPage - określa czy dana strona jest stroną błędu
  • errorPage - określa ścieżkę do strony, która ma być wywołana  w razie błędu na tej stronie
  • session - określa czy na danej stronie jest wykorzystywane mechanizm sesji
  • import - pozwala na importowanie klas/pakietów, w celu późniejszego wykorzystania 
  • isELIgnored - określa, czy elementy języka wyrażeń EL mają być ignorowane na danej stronie

      Stwórzmy bardzo prostą aplikację w środowisku NetBeans. Klient wchodząc na stronę poda swoje imię i hasło w formularzu, po zatwierdzeniu danych zostaje wyświetlona strona z imieniem i datą logowania.

      Stwórzmy na początku stronę odpowiadająca za pobranie danych od użytkownika, nazwijmy ją loginpage.jsp:




      Strona index.jsp zostanie zmodyfikowana w ten sposób, aby wyświetlała login, który podał klient. Strona wykorzystuje bibliotekę JSTL, powiemy sobie o niej następnym razem. Następuje odczyt w pętli atrybutów sesji. Atrybut ma nazwę User i odwołujemy się do niego przez sessionScope.User .User jest kolekcją zawierającą obiekty klasy User. Zmienna var="user" przechowuje pobrany obiekt z kolekcji. Wyświetlenie nazwy użytkownika i daty logowania odbywa się bardzo prosto: ${user.name} ${user.t} .
 



       Stworzymy też serwlet odpowiedzialny za pobranie danych z formularza i przekierowania żądania do strony index.jsp. W serwlecie korzystamy z mechanizmu sesji. Zapisujemy w niej kolekcję przechowującą obiekty klasy User. Po tym następuje przekierowanie żądania do strony index.jsp.



      Obiekt klasy User będzie odzwierciedlać klienta, przechowując jego login, hasło i datę logowania. Taka klasa, która spełnia kilka konwencji głównie  takich jak bez parametryczny konstruktor, udostępnianie atrybutów po przez metody pośredniczące get i set nazywamy JavaBean - ziarno kawy. Jak spojrzymy na nasz serwlet to zauważymy, że ustawiamy w zasięgu sesji atrybut o nazwie User będący kolekcją typu ArrayList, przechowującą obiekty klasy User.

     


Pozostaje, także do skonfigurowania deskryptor wdrożenia:




   
 Nasza aplikacja wygląda w następujący sposób:

      Formularz logowania:


      Strona index.jsp, która reprezentuje wprowadzone dane:


   

      W następnych częściach przyjrzymy się EL - językowi wyrażeń, JavaBeans - ziarna kawy, akcjom JSP, standardowej bibliotece tagów JSTL, modelowi JSP 1 i JSP 2 czyli wzorcowi MVC.

środa, 7 września 2011

JAVA EE6 Programowanie aplikacji WWW KURS cz. 7 Serwlety: kontener, kontekst i filtry

      Kontekst serwletów jest obiektem służącym do komunikacji serwletów z kontenerem.
Głównym zadaniem kontenera jest obsługa komunikacji między serwletami, a serwerem. Zarządza on cyklem życia serwletów, tworzy nowy wątek obsługujący żądanie. Kontener, także zajmuje się obsługą JSP, strony JSP tak naprawdę są serwletami.



      Kontener obsługując konkretne żądanie, które skierowane jest do serwletu po przez adres URL, tworzy dwa obiekty: HttpServletResponse i HttpServletRequest. W następnym kroku tworzy lub przydziela pamięć dla wątku, który obsługuje to żądanie. Obiekty reprezentujące żądanie i odpowiedź są przekazane do nowego wątku serwletu. Od tej pory mamy już gotowy serwlet. Następuje wywołanie metody service() serwletu. Metoda ta wywołuje metodę doGet() lub do Post(), w zależności naszego żądania. Jeśli nasze żądanie było typu GET to następuje jak się domyślasz wywołanie metody doGet().

     Dzięki kontekstowi serwletów możemy dynamicznie dodawać serwlety do aplikacji, a co najważniejsze korzystać z parametrów aplikacji webowej czyli kontekstu. Wcześniej pisałem o parametrach serwletów. Są one widoczne w ramach danego serwletu. Parametry konteksu są widoczne dla wszystkich serwletów w naszej aplikacji. Określamy je w bardzo podobny sposób co parametry serwletów:



Aby skorzystać z parametrów kontekstu musimy skorzystać z metody: getInitParameter(String name)




      Przejdźmy do filtrów. Filtry są mechanizmem umożliwiającym nam wykonanie operacji w momencie nadejścia żądania. Dzięki nim możemy np. odrzucić dane żądanie, które nie spełnia jakiś określonych parametrów. Filtry możemy podłączać do dowolnej grupy serwletów za pomocą znacznika url-pattern. Analogicznie do serwletów są deklarowane w deskryptorze wdrożenia. Kontener na podstawie znacznika url-pattern decyduje kiedy zostanie wywołany dany filtr. Kiedy ma być obsłużone żądanie, najpierw kontener przeszuka pasujące do adresu URL filtry i wywoła je, w takiej kolejności w jakiej są zadeklarowane w deskryptorze. Możemy mówić wtedy o sekwencji wywołań.


       Z technicznego punktu widzenia filtr jest klasą, która implementuje interfejs javax.servlet.Filter. Udostępnia on nam metody:

  • void init(FilterConfig fc) - metoda wywoływana jest przy utworzeniu filtru. Pozwala na uzyskanie obiektu interfejsu FilterConfig odpowiedzialnego za ustawienia filtru.
  • void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) - jest wywoływana w momencie nadejścia żądania. Interfejs FilterChain zapewnia komunikację pomiędzy filtrem, a servletem. 
  • void destroy() - metoda wywoływana przez serwer w momencie zakończenia działania filtru.


      W zależności od kolejności deklaracji filtrów w deskryptorze - web.xml, nasze żądanie HTTP przechodzi przez kolejne filtry dzięki metodzie doFilter(), w każdym filtrze. Po przejściu wszystkich filtrów, żądanie trafia do serwletu. Po zakończeniu obsługi żądania przez serwlet, sterowanie powraca do kolejnych filtrów.


       Stworzymy teraz bardzo prosty filtr. Zadaniem filtra będzie mierzenie czasu wykonania żądania.
Wspomnieliśmy wcześniej, że filtr to klasa implementująca interfejs Filter. Nasze żądanie zanim trafi do servletu, najpierw trafia do naszego filtru. Kiedy zostaje wykonywana metoda doFilter() zmiennej startTime przypisywany jest aktualny czas, następnie zostaje znowu wykonana metoda doFilter() z obiektu chain. Po jej wykonaniu nasze żądanie, przechodzi do właściwego  serwletu, gdzie po jego obsłużeniu znowu trafia do filtra, w miejsce po wywołaniu metody doFilter(), gdzie pobierany jest do zmiennej stopTime aktualny czas. Aby obliczyć czas wykonania żądania wystarczy te wartości od siebie odjąć.



      Tak jak w przypadku serwletów filtry konfigurujemy podobnie. Mamy dwie sekcje. Znacznik filter ,który wiąże klase filtru z abstrakcyjną nazwą i znacznik filter-mapping wiążacy nazwę z adresem URL.




Ciekawostką jest znacznik dispatcher . Pozwala on określić, czy filtr ma być stosowany w innych przypadkach niż w bezpośrednich żądaniach.