Wystarczy, że do tabeli, z której chcemy pobierać rekordy dodamy kolumnę np. random_num, najlepiej wesprzeć ją indeksem.  W kolumnie tej zapisywać będziemy losową liczbę z jakiegoś zakresu (np. 1 do 1000) podczas każdego zapisania obiektu.

Gdy mamy już tabelę wypełnioną  rekordami z losowymi wartościami  w kolumnie random_num (wartość ta oczywiście będzie się powtarzać w przypadku, gdy tabela ma > 1000 rekordów, ale to nie szkodzi), wystarczy wykonać dwa zapytania:

SELECT count(*) AS cnt FROM tabela

… by zliczyć ilość rekordów.  Wynik zapytania załadujmy do zmiennej cnt. W zmiennej limit natomiast zapamiętajmy ilość rekordów, jakie chcemy pobrać. Następnie:

SELECT * FROM tabela ORDER BY random_num OFFSET :offset LIMIT :LIMIT

Pod parametr :offset podstawiamy losową wartość (losowaną po stronie programu) z zakresu 1 do cnt – ilość rekordów, jakie chcemy pobrać, a pod :limit – wartość zmiennej limit.

Wadą tego rozwiązania jest jego „statyczność”, tzn dla każdego wylosowanego offsetu wynik zapytania będzie się powtarzał jeśli offest będzie się powtarzał. Jeśli jednak zawartość Twojej tabeli zmienia się dość często nie jest to problemem. Innym sposobem obejścia tego stanu rzeczy jest wykonywanie co jakiś czas „reindeksacji” kolumny random_num.

Jak uruchomić serwer NGINX ze wsparciem dla projektów Symfony pod Windows?

Ściągamy najnowszą wersję serwera NGINX – od niedawna istnieje wersja natywna, a nie cygwinowa, jakie były niedawno popularne. Natywna wersja powinnna być dużo szybsza od poprzedniczki. Serwer instalujemy w np. c:/dev/tools/nginx.

Zakładam, że system zarządzania bazą danych MySQL, framework Symfony, oraz sam PHP jest już zainstalowany na Twoim komputerze. Zakładam też, że zarówno MySQL, jak i PHP przygotowane są do współpracy z Symfony. Jeśli nie – w sieci jest mnóstwo opisów jak to zrobić.

Aby łatwo było uruchamiać i zatrzymywać serwer NGINX, musimy utworzyć następujące skrypty i zapisać je w katalogu NGINXa:

start-nginx.bat

@echo off
set NGINX_HOME=c:/dev/tools/nginx
set PHP_HOME=c:/dev/tools/php
set FASTCGI_ADDR=127.0.0.1
set FASTCGI_PORT=9000
 
echo "Startujemy nginx"
start %NGINX_HOME%/nginx.exe
echo "Startujemy php-cgi"
start /B %PHP_HOME%/php-cgi.exe -b %FASTCGI_ADDR%:%FASTCGI_PORT% -c %PHP_HOME%/php.ini
exit

stop-nginx.bat

@echo off
taskkill /f /IM nginx.exe
taskkill /f /IM php-cgi.exe
exit

Teraz wystarczy tylko skonfigurować NGINX tak, by

• pozwalał na wykonywanie skryptów PHP za pomocą fastCGI
• pozwalał na uruchamianie skryptów napisanych we frameworku Symfony

Edytujemy skrypt konfiguracyjny NGINXa (conf/nginx.conf):

worker_processes  1;
 
events {
    worker_connections  64;
}
 
http {
    include       mime.types;
    default_type  application/octet-stream;
 
    client_header_timeout   10m;
    client_body_timeout     10m;
    send_timeout            10m;
 
    connection_pool_size            256;
    client_header_buffer_size       1k;
    large_client_header_buffers     4 2k;
    request_pool_size               4k;
 
    gzip on;
    gzip_min_length 1100;
    gzip_buffers    4 8k;
    gzip_types      text/plain;
 
    output_buffers  1 32k;
    postpone_output 1460;
 
    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;
 
    keepalive_timeout       75 20;
    ignore_invalid_headers  on;
 
server {
    set  $docroot     c:/dev/php/symfony/myproject;
    root $docroot/web;
    index  index.php;
 
    listen       80;
    server_name  localhost;
 
    log_format main
                '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '"$gzip_ratio"'; 
    access_log  $docroot/log/myproject.access.log  main;
 
    charset utf-8;
 
    location / {
        if (-f $request_filename) {
            expires max;
            break;
        }
        rewrite ^(.*)/index.php last;
    }
 
    location /sf/ {
          root c:/dev/tools/php/data/symfony-1.2.7/data/web;
    }            
 
    location ~ \.php($|/) {
        set $the_uri $uri;
        if ($the_uri ~ "^(.+)/$") {
            set $the_uri    $1;
        }
 
        set  $script     $the_uri;
        set  $path_info  "";
 
        if ($uri ~ "^(.+\.php)(/.+)") {
            set  $script     $1;
            set  $path_info  $2;
        }
 
        fastcgi_index   index.php;
        fastcgi_pass   127.0.0.1:9000;
        include fastcgi_params;
 
        fastcgi_param  SCRIPT_FILENAME  $docroot/web$script;
        fastcgi_param  SCRIPT_NAME      $script;
        fastcgi_param  PATH_INFO        $path_info; 
        fastcgi_param  SERVER_NAME      $host;
    }
 
    location ~ /\.ht {
        deny  all;
    }
  }    
}

Pliczek konfiguracyjny NGINX’a jest dość czytelny i łatwo go zrozumieć (łatwo go też rozbudować i zoptymalizować jeśli np. używamy virtual-hostów). Na uwagę zasługuje jednak fakt, że przed przekazaniem argumentów do FastCGI musimy nieco „rozpracować” żądanie i wydobyć z niego zmienne $script i $path_info, ewentualnie usuwając zakańczający je znak slash (zmienna $the_uri). Warto też odnotować, że NGINX wspiera znane z Apacza aliasy – widoczna tu sekcja location /sf/.
Zauważ, że port 9000 wspomniany jest także w skrypcie startującym NGINX – możesz wybrać dowolny inny większy niż 1024 (niższe wymagają roli administratora i są zarezerwowane dla tzw. well-known-services).

Gotowe, teraz możemy uruchamiać NGINX poleceniem start-nginx.bat (z katalogu NGINXa) i zatrzymywać poprzez stop-nginx.bat.
Nasz projekt powinien być dostępny pod adresem http://localhost/ – czy to zakończonym slashem, czy tez nie.

Oczywiście nie jest to konfiguracja idealna – wspiera tylko jeden projekt (myproject), ale daje dobre podstawy do zbudowania konfiguracji dla wielu projektów i osobnych virtual-hostów dla każdego z nich. Warto wiedzieć, że konfiguracja NGINXa wspiera dyrektywę include, dzięki której możliwe jest importowanie konfiguracji z zewnętrznych plików konfiguracyjnych (np. po jednym dla każdego virtual-hosta) np. z sekcjami server.

• dopuszczać tylko zalogowanych użytkowników (tak, jak poprzednio),
• pozwalać na oglądanie zasobów wszystkim zalogowanym użytkownikom (posiadającym rolę „users”),
• pozwalać na edycję/usuwanie/tworzenie nowych zasobów tylko użytkownikom posiadającym rolę „admin” (pozostali użytkownicy dostają informację o braku dostępu)

Jak widzisz, wykorzystamy szkielet poprzedniej aplikacji. Zauważ też, że wprowadzamy pojęcie roli, czym jest rola?
Zgodnie z infomacją na stronie wtyczki, to

a job or a set of responsibilities that a person can have

, czyli zbiór odpowiedzialności, które posiada dany użytkownik w systemie. System, oczywiście, musi takiemu użytkownikowi udostępnić możliwość wykonania czynności wchodzących w skład takich odpowiedzialności. Upraszczając – posiadanie danej roli pozwala na dostęp do zasobów systemu, do których dostęp bez niej jest zabroniony.
Założeniem naszej aplikacji jest, aby każdy zalogowany użytkownik mógł oglądać dane, jednak modyfikacja jakichkolwiek informacji wiąże się z obowiązkiem posiadania roli admina.

Zaczynajmy.

1. Dodajemy nowe klasy dziedzinowe

Musimy zdefiniować nowe klasy dziedzinowe, które pozwolą nam utrwalać informacje o rolach i powiązaniach ich z użytkownikami.

class Role {
    String name
}

class UserRoleRef {
    User user
    Role role
}

Dzięki takim klasom dziedzinowym (i klasie User z poprzedniego wpisu) możliwa będzie realizacja referencji wiele-do-wielu – jeden użytkownik może mieć wiele ról w systemie, a jedna rola może być w posiadaniu wielu użytkowników.

Możemy teraz zapisać wstępnie uprawnienia dostępu do naszego systemu, np. tak:

// użytkownicy
def jasiu = new User(username: "jasiu", password: new Sha1Hash("sekret").toHex()).save()
def admin = new User(username: "admin", password: new Sha1Hash("admin").toHex()).save()
 
// role
def usersRole = new Role("users").save()
def adminRole = new Role("admin").save()
 
// powiązania user-role
new UserRoleRef(user: jasiu, role: usersRole).save()
new UserRoleRef(user: admin, role: adminRole).save()

2. Uaktualniamy filtr

Role i powiązania z użytkownikami mamy już zdefiniowane i zapisane w bazie danych, jednak wciąż nie wiemy po co nam one. Samo posiadanie praw „admina” nic nie daje, jeśli nie wiemy, co one dają. Uaktualniamy nasz plik SecurityFilters.groovy tak:

class SecurityFilters {
    def filters = {
        auth(controller: "*", action: "*") {
            before = {
                accessControl { true }
            }
        }
 
        manageRecord(controller: "*", action: "(create|edit|save|update|delete)") {
            before = {
                accessControl {
                    role("admins")
                }
            }
        }
 
        showRecord(controller: "*", action: "show") {
            before = {
                accessControl {
                    role("admins") || role("users")
                }
            }
        }
    }
}

Jak widać, mamy zdefiniowane dwie reguły dostępu do dowolnego kontrolera (gwiazdka), ale z wyszczególnionymi akcjami. Akcja show wymaga posiadania roli „users”, albo „admins” (czyli dowolnej, na chwilę obecną), a akcje pozwalające na modyfikacje informacji – roli „admins”.

3. Rozszerzamy funkcjonalność MyRealm

Czas na fragment kodu, który będzie odpowiadał za sprawdzanie, czy dany użytkownik posiada daną rolę. Wzbogacamy naszą klasę MyRealm w dwie dodatkowe (poza authenticate()) metody:

    def hasRole(principal, roleName) {
        def criteria = UserRoleRef.createCriteria()
        def roles = criteria.list {
            role {
                eq('name', roleName)
            }
            user {
                eq('username', principal)
            }
        }
 
        return roles.size() > 0
    }
 
    def hasAllRoles(principal, roles) {
        def criteria = UserRoleRef.createCriteria()
        def r = criteria.list {
            role {
                'in'('name', roles)
            }
            user {
                eq('username', principal)
            }
        }
 
        return r.size() == roles.size()
    }

Obie są dość proste – pierwsza sprawdza istnienie referencji użytkownik-rola dla zadanych parametrów, druga metoda robi to samo, ale ze zbiorem ról zadanych jako parametr.

4. Dodajemy widok informujący o braku dostępu

Założenia mamy takie, żeby użytkownik bez dostępu do konkretnego zasobu został o tym poinformowany komunikatem. W tym celu wprowadzamy drobne usprawnienie do naszego kontrolera AuthController. Wprowadzamy domknięcie unauthorized, które będzie wykonane za każdym razem, gdy użytkownik spróbuje wykonać akcję, do której nie ma dostępu.

def unauthorized = {
}

… oraz plik widoku dla takiej akcji (views/auth/unauthorized.gsp):

<%@ page contentType="text/html;charset=UTF-8" %>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Brak dostępu</title>
  </head>
  <body>
    <h1>Dostęp zabroniony</h1>
  </body>
</html>

5. Uaktualnianie menu

Nasze zabezpieczanie właściwie się zakończyło, jednak warto jeszcze zadbać o dodatkową rzecz. Jeśli pracujemy na widokach wygenerowanych przez Grails (np. za pomocą komendy grails generate-all <klasa_dziedzinowa>), to każdy z widoków wyposażony jest w przyciski/odnośniki kierujące do stron pozwalających na modyfikację/dodawanie/usuwanie rekordów, np. takich:

<div class="nav">
    <span class="menuButton"><a class="home" href="${createLinkTo(dir:'')}">Home</a></span>
    <span class="menuButton">New Book</span>
</div>

Teoretycznie nic się nie stanie, jeśli tak to zostawimy, bo nawet kliknięcie na link New Book nie spowoduje wygenerowania formularza tworzenia nowej książki, tylko skieruje nas do strony z informacją o braku dostępu. Jednak… czego oczy nie widzą, tego sercu nie żal :) więc warto ukryć przed użytkownikiem te pozycje menu, które nie są mu potrzebne. Wykorzystamy więc znacznik jsec:hasRole:

<div class="nav">
    <span class="menuButton"><a class="home" href="${createLinkTo(dir:'')}">Home</a></span>
    <jsec:hasRole name="admins">
        <span class="menuButton"><g:link class="create" action="create">New Book</g:link></span>
    </jsec:hasRole>
</div>

Od tej pory odnośnik New Book pokaże się tylko użytkownikom posiadającym rolę „admins”. Takie modyfikacje możemy wprowadzić we wszystkich widokach naszej aplikacji.

I to właściwie wszystko jeśli chodzi o kontrolę ról za pomocą JSecurity w Grails.

Dość ciekawą rzeczą, która warta jest poznania, ale nie opisałem jej tutaj (miało być prosto, więc nie chciałem dodatkowo komplikować) jest kontrola uprawnień za pomocą JSecurity. Wtyczka dla Grails pozwala na kontrolę uprawnień nie tylko na poziomie kontroler/akcja, ale też np. dostępu do plików, albo innych zasobów systemowych.

Poniższy wpis jest oparty właśnie na wspomnianym wyżej QuickStarcie, jednak został uproszczony i ograniczony jedynie do mechanizmu autentykacji uwierzytelnienia, nie zaś autoryzacji (kontroli dostępu do zasobów) użytkowników.

Dostęp do aplikacji z JSecurity jest realizowany za pomocą przestrzeni (ang. realms), można skonstruować mechanizm autentykacji uwierzytelnienia (i autoryzacji) na różne sposoby, np. za pomocą katalogów LDAP, loginów systemowych, usług sieciowych itd. My wykorzystamy najbardziej tradycyjny mechanizm: sprawdzania użytkowników zapisanych w bazie danych. JSecurity realizuje mechanizm weryfikacji dostępu do poszczególnych zasobów systemu za pomocą przynależności użytkowników do ról, jednak mój przykład będzie znacznie prostszy – wystarczy, że użytkownik będzie istniał w bazie danych, a już będzie miał dostęp do zasobów systemu.

Oto jak wzbogacić naszą aplikację o wymaganie autentykacji uwierzytelniania użytkowników, kompletnie nie zajmując się kwestiami autoryzacji dostępu do zasobów (wszyscy zalogowani użytkownicy mają dostęp):

1. Instalujemy wtyczkę

grails install-plugin jsecurity

2. Tworzymy klasę dziedzinową użytkownika:

class User {
    String username
    String password
 
    static mapping = {
        table "users"
    }
 
    public String toString() {
        username
    }
}

Używam tutaj mapowania na inną niż domyślna nazwę tabeli (domyślnie byłaby „user”, a ja dałem „users”) – taką kiedyś mi wpojono konwencję, by tabele miały nazwy w liczbie mnogiej. Z kolei metoda toString() przyda się nam nieco później.

Sama tabelka nie wystarczy, trzeba jeszcze użytkownika zapisać w bazie. Możemy to zrobić używając poniższego fragmentu kodu:

new User(username: "jasiu", password: new Sha1Hash("sekret").toHex()).save()

Jak widzisz, hasło jest kodowane za pomocą algorytmu Sha1 (kodowanie to wspierane jest przez JSecurity), nie obędzie się więc bez:

import org.jsecurity.crypto.hash.Sha1Hash

3.  Dodajemy do katalogu grails-app/conf/ pliczek SecurityFilters.groovy o zawartości:

class SecurityFilters {
    def filters = {
        auth(controller: "*", action: "*") {
            before = {
                accessControl { true }
            }
        }
    }
}

Ten filtr spowoduje, że wszystkie żądania (gwiazdki oznaczają dowolny kontroler, i dowolną akcję) zostaną poddane działaniu naszego filtra, a ten, przed wykonaniem żądania, wymusi na nim sprawdzenie praw dostępu.

4. W katalogu realms/ tworzymy klasę MyDbRealm, o postaci:

import org.jsecurity.authc.AccountException
import org.jsecurity.authc.IncorrectCredentialsException
import org.jsecurity.authc.UnknownAccountException
import org.jsecurity.authc.SimpleAccount
 
class MyDbRealm {
    static authTokenClass = org.jsecurity.authc.UsernamePasswordToken
 
    def authenticate(authToken) {
        def username = authToken.username;
        def user = User.findByUsername(username);
        if (!user) {
            throw new UnknownAccountException("Użytkownik ${username} nie istnieje w bazie danych")
        }
 
        def account = new SimpleAccount(username, user.password, "MyDbRealm")
        if (!credentialMatcher.doCredentialsMatch(authToken, account)) {
            log.info 'Nieprawidłowe hasło dla użytkownika ${user.username}'
            throw new IncorrectCredentialsException("Nieprawidłowe hasło dla użytkownika ${user.username}")
        }
        return user;
    }
}

5. Tworzymy kontroler naszego mechanizmu uwierzytelniania AuthController (zapisujemy go oczywiście w katalogu controllers/ naszej aplikacji):

import org.jsecurity.authc.AuthenticationException
import org.jsecurity.authc.UsernamePasswordToken
import org.jsecurity.SecurityUtils
 
class AuthController {
    def jsecSecurityManager
 
    def index = { redirect(action: 'login', params: params) }
 
    def login = {
        return [ username: params.username, targetUri: params.targetUri ]
    }
 
    def signIn = {
        def authToken = new UsernamePasswordToken(params.username, params.password)
 
        try{
            this.jsecSecurityManager.login(authToken)
            def targetUri = params.targetUri ?: "/"
            redirect(uri: targetUri)
        }
        catch (AuthenticationException ex){
            log.info "Błąd logowania użytkownika: '${params.username}'."
            flash.message = "Logowanie nieudane"
 
            def m = [ username: params.username ]
            if (params.targetUri) {
                m['targetUri'] = params.targetUri
            }
 
            redirect(action: 'login', params: m)
        }
    }
 
    def signOut = {
        SecurityUtils.subject?.logout()
        redirect(uri: '/')
    }
}

6. Tworzymy okienko logowania (views/auth/login.gsp):

 
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <meta name="layout" content="main" />
  <title>Login</title>
</head>
<body>
  <g:if test="${flash.message}">
    <div class="message">${flash.message}</div>
  </g:if>
  <g:form action="signIn">
    <input type="hidden" name="targetUri" value="${targetUri}" />
    <table>
      <tbody>
        <tr>
          <td>Username:</td>
          <td><input type="text" name="username" value="${username}" /></td>
        </tr>
        <tr>
          <td>Password:</td>
          <td><input type="password" name="password" value="" /></td>
        </tr>
        <tr>
          <td />
          <td><input type="submit" value="Zaloguj" /></td>
        </tr>
      </tbody>
    </table>
  </g:form>
</body>
</html>

7. Modyfikujemy nasz główny layout tak, by pokazał czy i jako kto jesteśmy zalogowani:

<jsec:isLoggedIn>
    <div>Witaj <jsec:principal/>! (<g:link controller="auth" action="signOut">Wyloguj</g:link>)</div>
</jsec:isLoggedIn>

I tu właśnie przydała nam się metoda toString() klasy User, albowiem znacznik jsec:principial zwróci nam właśnie wartość obiektu, który przedstawia zalogowanego aktualnie użytkownika (to, co zwróciła metoda authenticate() klasy MyDbRealm), a ten reprezentowany jest właśnie przez toString().
Tag jsec:isLoggedIn wraz z zawartością umieszczamy np. nad użyciem znacznika g:layoutBody. Dla chcących potestować inne tagi dostarczane przez wtyczkę polecam lekturę ich listy.

Gotowe, aplikacja zabezpieczona, a my możemy spać spokojnie :)

I na koniec, dwa linki, jako uzupełnienie tematu zabezpieczania aplikacji Grails z JSecurity:

• http://tramuntanal.wikidot.com/jsecurityplugin
• http://asrijaffar.blogspot.com/2008/08/grails-jsecurity-plugin.html
]]> http://xis.schowek.net/2009/03/15/proste-uwierzytelnianie-w-grails-z-jsecurity/feed/ 4 http://xis.schowek.net/2009/03/11/upiekszanie-jtable/ http://xis.schowek.net/2009/03/11/upiekszanie-jtable/#comments Wed, 11 Mar 2009 11:15:32 +0000 xis http://xis.schowek.net/?p=289 Przy okazji moich zabaw ze Swingiem – krótko o tym jak ulepszyć JTable.

Mamy sobie JTable taką:



A będziemy chcieli taką:



Wzbogacimy więc naszą tabelkę o bardzo ładne oznaczenie numerów wierszy, oraz kolorowanie co drugiego rekordu.

Zabieg pierwszy: kolorowanie co drugiego wiersza

Aby używać warunkowego kolorowania wierszy, musimy wskazać naszej tabelce, by wykorzystała obiekt klasy pochodnej od DefaultTableCellRenderer, np. takiej:

class ColorCellRenderer extends DefaultTableCellRenderer {
 
    @Override
    public Component getTableCellRendererComponent( JTable table, Object val, boolean selected, boolean focused, int row, int col ) {
        Component comp = super.getTableCellRendererComponent( table, val, selected, focused, row, col );
        if( selected == false ) {
            if( ( row % 2 ) == 1 ) {
                comp.setBackground( color );
            }
            else {
                comp.setBackground( null );
            }
        }
        return comp;
    }
}

Zabieg drugi: numeracja wierszy

Na forum Suna znalazłem b. stary, ale nadal ciekawy przykład rozwiązania tego problemu. Budujemy klasę LineNumberTable, która dziedziczy po JTable:

public class LineNumberTable extends JTable {
    private JTable mainTable;
 
    public LineNumberTable( JTable table ) {
        super();
        mainTable = table;
        setAutoCreateColumnsFromModel( false );
        setModel( mainTable.getModel() );
        setSelectionModel( mainTable.getSelectionModel() );
        setAutoscrolls( false );
 
        addColumn( new TableColumn() );
        getColumnModel().getColumn( 0 ).setCellRenderer( mainTable.getTableHeader().getDefaultRenderer() );
        getColumnModel().getColumn( 0 ).setPreferredWidth( 30 );
        setPreferredScrollableViewportSize( getPreferredSize() );
    }
 
    @Override
    public boolean isCellEditable( int row, int column ) {
        return false;
    }
 
    @Override
    public Object getValueAt( int row, int column ) {
        return new Integer( row + 1 );
    }
 
    @Override
    public int getRowHeight( int row ) {
        return mainTable.getRowHeight();
    }
}

OK, teraz wystarczy wykorzystać utworzone klasy w naszej JTable:

    public MyPanel() {
        initComponents();
        // wskazujemy nowy renderer, dla obiektów wszystkich typów naszej tabelki
        jTable1.setDefaultRenderer( Object.class, new ColorCellRenderer() );
        // scrollPane, którym mamy osadzoną tabelę dekorujemy oznaczeniem numerów wierszy
        jScrollPane1.setRowHeaderView( new LineNumberTable( jTable1 ) );
    }

Gotowe. Prawda, że ładniej?

]]> http://xis.schowek.net/2009/03/11/upiekszanie-jtable/feed/ 3 http://xis.schowek.net/2009/03/08/netbeans-i-ujednolicanie-jdialog/ http://xis.schowek.net/2009/03/08/netbeans-i-ujednolicanie-jdialog/#comments Sun, 08 Mar 2009 11:29:14 +0000 xis http://xis.schowek.net/?p=242 Miałem niedawno okazję dłużej popracować nad projektami Javy w NetBeans 6.5 (wcześniej poważniej NetBeans używałem tylko do Grails). Środowisko to nie było dotychczas moim ulubionym, głównie ze względu na wydajność, co do której można mieć spore zastrzerzenia, jednak zauważyłem, że ma ono również mnóstwo zalet. Pierwszą jaką dostrzegłem jest to, że projekty generowane przez to IDE są naprawdę ładnie utworzone, wykorzystują standardowe narzędzia Javy, takie jak np. Ant i nie uzależniają użytkownika od używania „jedynego i właściwego” IDE. NetBeans może zauroczyć również stopniem dopracowania swoich elementów – jak już coś wspiera, to wspiera naprawdę dobrze. Przykładem tu może być sposób, w jaki można za pomocą tego środowiska utworzyć i zarządzać aplkacjami wykorzystującymi Web Services w aplikacji – zarówno klientem, jak i usługą wykorzystującącymi API JAX-WS. Kolejny (lecz na pewno nie ostatni) plus należy się NetBeans za właściwie bezkonkurencyjny edytor wizualny aplikacji wykorzystujących Swing.

I o Swingu właśnie będzie ten wpis (nieco przydługi, ostrzegam).

Nie do końca podoba mi się domyślna filozofia okien dialogowych w Javie. Np. rozmiar – niby można zmieniać rozmiar „świeżo” utworzonego okienka dialogowego rozciągając je, ale menadżery okien nie pozwalają na jego maksymalizację (brakuje bowiem przycisku maksymalizacji). Wiem, że takie jest założenie okienek dialogowych, ale wyczuwam tu pewną niekonsekwencję. Ponadto „goły” JDialog jest praktycznie pozbawiony funkcjonalności, np. brakuje mu domyślnych zachowań takich jak potwierdzanie i anulowanie, reakcję na przycisk Escape i Enter – te braki sprawiają, że każda implementacja okienka dialogowego musi być poprzedzona żmudnym wykonywaniem tych banalnych czynności.

Postanowiłem więc wykonać coś na wzór bazy dla okna dialogowego, która to baza będzie wyposażona we wszystkie cechy, które wg mnie posiadać powinna każda implementacja JDialog. W takiej bazie będę umieszczał różne komponenty – w zależności od tego, jakiego dialogu potrzebuję.



Chcę uzyskać bazę dla dialogu, w której będę umieszczał przeróżne panele – począwszy od prostych, informacyjnych (wtedy taki dialog przypominałby funkconalnością JOptionPane), skończywszy na całkiem zaawansowanych funkcjonalnie formularzach edycji wykorzystujących panele, które przygotuję sobie osobno (dzięki temu będę mógł wykorzystać panele także w innych sytuacjach). Wszystkie jednak dialogi cechować się mają wspólnymi właściwościami: dialog można zatwierdzić (submit), albo odrzucić (cancel). Wciśnięcie Escape na aktywnym oknie powoduje jego zamknięcie (funkcjonalność identyczna do wciśnięcia przycisku Anuluj), a Enter – zatwierdzenie (kliknięcie OK).

W tym celu zbudowałem JDialog w NetBeans wybierając z menu projektu New->JDialog Form i nazwałem go DialogBase. W edytorze wizualnym umieściłem dwa przyciski (nazwałem je jBtnOK i jBtnCancel), oraz jeden JPanel (jPanelMain), z ustawionym layoutem BorderLayout – w tym panelu będę umieszczał przeróżne panele „implementacyjne” – w zależności od przeznaczenia mojego dialogu.

Na początek, domyślny konstruktor i obsługa własności panel (czyli obiekt panelu, który umieszczamy w oknie):

    private JPanel panel;
 
    public DialogBase(JPanel panel) {
        this( null, true );
        setLocationRelativeTo(null);
        setPanel(panel);
    }
 
    protected void setPanel(JPanel panel) {
        this.panel = panel;
        jPanelMain.removeAll();
        jPanelMain.add( panel, BorderLayout.CENTER );
        panel.setVisible( true );
        Dimension d = new Dimension(panel.getPreferredSize());
        this.setSize( d.width, d.height+70 );
    }
 
    protected JPanel getPanel() {
        return panel;
    }

Metoda setPanel() ustawia własność panel oraz zajmuje się osadzeniem go w oknie dialogu i ustawieniem odpowiedniego rozmiaru okna (wysokość zwiększam o wielkość przycisków na dole okna).

Aby wiedzieć w jaki sposób moje okno dialogowe zostało zamknięte, wyposażam je we własność exitStatus:

    public static final int DLG_EXIT_CANCEL = 0;
    public static final int DLG_EXIT_OK = 1;
 
    private int exitStatus = DLG_EXIT_CANCEL;
 
    // getter i setter

Domyślne zamknięcie okna poskutkuje zapamiętaniem statusu „Cancel”.

Czas na obsługę klawisza Escape i Enter. Posiłkując się ciekawym na ten temat artykułem, wzbogaciłem mój DialogBase o następujący kod:

    @Override
    protected JRootPane createRootPane() {
        JRootPane theRootPane = new JRootPane();
 
        KeyStroke escStroke = KeyStroke.getKeyStroke( KeyEvent.VK_ESCAPE, 0 );
        theRootPane.registerKeyboardAction( new ActionListener() {
            public void actionPerformed( ActionEvent actionEvent ) {
                doCancel();
            }
        }, escStroke, JComponent.WHEN_IN_FOCUSED_WINDOW );
 
        KeyStroke entStroke = KeyStroke.getKeyStroke( KeyEvent.VK_ENTER, 0 );
        theRootPane.registerKeyboardAction( new ActionListener() {
            public void actionPerformed( ActionEvent actionEvent ) {
                doSubmit();
            }
        }, entStroke, JComponent.WHEN_IN_FOCUSED_WINDOW );
 
        return theRootPane;
    }

Jak widzisz, wykorzystuję tu tajemnicze metody doSubmit() i doCancel(). Co to za metody?

    private void doSubmit() {
        if( onSubmit() ) {
            setExitStatus( DLG_EXIT_OK );
            dispose();
        }
    }
 
    private void doCancel() {
        if( onCancel() ) {
            setExitStatus( DLG_EXIT_CANCEL );
            dispose();
        }
    }
 
    protected boolean onSubmit() {
        return true;
    }
 
    protected boolean onCancel() {
        return true;
    }

Obie metody działają dość podobnie: jeśli metoda onSubmit() (lub analogicznie onCancel()) zwróci true, ustawiamy odpowiedni exitStatus i zamykamy okno. Zarówno doSubmit() jak i doCancel() wiążę też za pomocą zdarzenia ActionEvent z przyciskami (wystarczy dwukrotnie kliknąć na przycisku w edytorze wizualnym i wyedytować wygenerowaną przez NetBeans pustą metodę):

    private void jBtnCancelActionPerformed(java.awt.event.ActionEvent evt) {
        doCancel();
    }
 
    private void jBtnOKActionPerformed(java.awt.event.ActionEvent evt) {
        doSubmit();
    }

OK, ale po co nam te trywialne metody onSubmit() i onCancel()? Wykorzystamy je np. do walidacji w przyszłych implementacjach naszych okien dialogowych (jeśli zdecydujemy się na ich przesłonięcie, jeśli nie – niczego złego nie zrobią ;) ).

Wygląda na to, że nasza baza jest gotowa. Użyjmy jej więc na jakimś przykładzie – np. formularzu logowania.

W NetBeans, tworzymy nowy JPanel Form, nazywamy go PanelLogin i dodajemy odpowiednie elementy interfejsu użytkownika (jak na załączonym wyżej szkicu), oczywiście to ten panel będziemy osadzać w bazie dialogu, więc nie dodajemy już przycisków OK i Anuluj, bo nie musimy. Element JTextField, zawierający nazwę użytkownika nazywamy jTxtUsername, a JPasswordField (z hasłem) – jTxtPassword.
Dodajemy dwie publiczne metody do pobrania wprowadzonych nazwy użytkownika i hasła:

    public String getUsername() {
        return jTxtUsername.getText();
    }
 
    public String getPassword() {
        return new String(jTxtPassword.getPassword());
    }

A teraz nasz dialog logowania.
W NetBeans tworzę nową klasę Javy (New->Java Class), a nie dialog(!) i nazywam ją DialogLogin. Nasza nowa klasa musi dziedziczyć po DialogBase. Ponadto, nasz dialog powinien zwracać obiekt użytkownika (jakiejś klasy np. User, której szczegóły nie są tu istotne) jeśli logowanie się powiedzie. W tym celu powołujemy własność returnValue (wraz z getterem i setterem). Przy okazji dodaję też licznik prób logowania – proste umożliwienie trzykrotnej pomyłki przy logowaniu.

public class DialogLogin extends DialogBase {
    private User returnValue;
    private int tries = 3;
 
    public DialogLogin() {
        super(new PanelLogin());
    }
}

Czas na obsługę logiki biznesowej naszego dialogu. Anulowanie dialogu zostawiamy bez zmian – po prostu zamykamy okno. Jednak musimy zaimplementować obsługę zatwierdzania formularza. W tym celu przesłaniamy naszą metodę onSubmit():

    @Override
    protected boolean onSubmit() {
        PanelLogin thePanel = ( PanelLogin ) this.getPanel();
 
        User u = App.login( thePanel.getUsername(), thePanel.getPassword() );
        if( u == null ) {
            JOptionPane.showMessageDialog( this, "Nie udało się zalogować");
            return (--tries<=0);
        }
 
        returnValue = u;
        return true;
    }

Jeśli App.login() (przyjmijmy, że ta metoda odpowiada za autoryzację aplikacji) zwróci null, to znaczy, ze nie zalogowaliśmy się do aplikacji – dialog nie zamknie się, ale pokaże nam info o nieprawidłowych parametrach logowania (i tak do momentu aż wartość tries osiągnie wartość mniejszą lub równą zeru). Jeśli użytkownik jest prawidłowy, dialog zamknie się ustawiwszy uprzednio własność returnValue.

Powinno działać. Sprawdźmy:

    public static void main(String[] args) {
        try {
            UIManager.setLookAndFeel( UIManager.getSystemLookAndFeelClassName() );
        }
        catch( Exception ex ) {}
 
        DlgLogin dlg = new DlgLogin();
        dlg.setVisible( true );
        System.err.println("Logowanie zakończone: "+dlg.getExitStatus());
        if( dlg.getExitStatus() == DialogBase.DLG_EXIT_OK ) {
            if( dlg.getReturnValue() != null ) {
                System.err.println("W porządku, użytkownik prawidłowy");
            }
            else {
                System.err.println("Brak dostępu!");
            }
        }
        else {
            System.err.println("Anulowano!");
        }
    }

Voila!

We wpisie użyłem ikon Free Business Icons opublikowanych na licencji Creative Commons oraz Silk na licencji LGPL.

]]> http://xis.schowek.net/2009/03/08/netbeans-i-ujednolicanie-jdialog/feed/ 4 http://xis.schowek.net/2009/02/01/grails-datatable-z-filtrem-i-pagerem/ http://xis.schowek.net/2009/02/01/grails-datatable-z-filtrem-i-pagerem/#comments Sun, 01 Feb 2009 12:00:19 +0000 xis http://xis.schowek.net/?p=221 Mojej przygody z Grails ciąg dalszy. Zauważyłem, że framework ten posiada bardzo wiele fajnych wtyczek. Jedną z nich jest grails-ui, który korzystając z dobrodziejstw Yahoo! User Interface Library pozwala na wstawianie ciekawych komponentów na stronę za pomocą zaledwie jednego znacznika GSP. Jednym z takich komponentów jest DataTable, bazujący na yui:dataTable, pozwalający np. na pobieranie danych za pomocą żądań asynchronicznych AJAX w formacie JSON (lub XML, wedle życzenia), dzielenie wyników na podstrony (pager), mechanizm skórek itd. Znacznik GSP gui:dataTable posiada wiele opcjonalnych atrybutów, którymi można skonfigurować naszą tabelę z danymi (ilość maksymalna wierszy na jednej podstronie, format danych, kolumny itd.). Mam jednak wrażenie, że autor wtyczki nie pomyślał o możliwości dołączenia do naszej tabeli filtrowania wyników. Owszem, w Sieci można znaleźć przykłady filtrowania dla ‘gołego’ yui:dataTable, ale większość z nich, albo nie wspiera cięcia na podstrony, albo filtruje wyniki dopiero po stronie klienta (a z serwera pobiera pełną listę danych). Dla mnie to niestety za mało.

Oto przykład na to, jak korzystając ze znacznika GSP gui:dataTable zaimplementować dataTable, który daje się połączyć z prostym filtrem wyników.

Do przedstawienia przykładu wykorzystam dane dostępne na stronie z przykładami użycia dataTable w YUI.  Załóżmy więc, że mam bazę danych restauracji (pizzerii).



Użyję więc klasy dziedzinowej (ang. domain class) Restaurant o postaci:

class Restaurant {
    String title
    String address
    String city
    String state
}

Listę tę chcę mieć dostępną pod adresem http://localhost:8080/PagedDatatable/restaurant/list, czyli potrzebny mi będzie kontroler RestaurantController, a w nim metoda list. W metodzie tej, kontroler nie ma zbyt wiele roboty – po prostu serwuje statyczną stronę, toteż jej postać jest taka:

    def list = {
    }

Niezbyt skomplikowane, prawda? :) Pusta metoda sprawi, że kontroler od razu zabierze się za renderowanie wyniku, strony GSP, która wygląda tak:

<g:javascript library="yui" />
<gui:resources components="['dataTable']"/>
 
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <meta name="layout" content="main" />
    <title>Restaurant List</title>
  </head>
  <body>
    <div class="yui-skin-sam" style="width: 600px;">
      <label for="fltr[title]">Title:</label><input type="text" id="fltr[title]" value="">
      <label for="fltr[city]">City:</label><input type="text" id="fltr[city]" value="">
      <button id="filterButton">Filter</button><br/>
 
      <gui:dataTable
        id="myDataTable"
        controller="restaurant"
        action="listAsJSON"
        rowsPerPage="15"
        sortedBy="title"
        columnDefs="[
        [key:'title', label:'Title'],
        [key:'address', label: 'Address'],
        [key:'city', label: 'City'],
        [key:'state', label: 'State']
        ]"
        />
 
    </div>
 
    <script>
      YAHOO.util.Event.onDOMReady(function () {
 
        updateFilter  = function () {
          GRAILSUI.myDataTable.customQueryString =
            "title="+YAHOO.util.Dom.get("fltr[title]").value+"&"+
            "city="+YAHOO.util.Dom.get("fltr[city]").value;
 
          var state = GRAILSUI.myDataTable.getState();
          // gui:dataTable odwołuje się do własności sorting obiektu state,
          // podczas gdy yui oferuje jedynie własność sortedBy (czyżby bug?)
          // kopiujemy własność, by uniknąć błędu
          state.sorting = state.sortedBy;
          // reset pagera, zawsze po filtrowaniu wracamy do pierwszej strony
          state.pagination.recordOffset = 0;
          query = GRAILSUI.myDataTable.buildQueryString(state);
 
          GRAILSUI.myDataTable.getDataSource().sendRequest(query,{
            success : GRAILSUI.myDataTable.onDataReturnReplaceRows,
            failure : GRAILSUI.myDataTable.onDataReturnReplaceRows,
            scope   : GRAILSUI.myDataTable,
            argument: state
          });
        };
 
        YAHOO.util.Event.on('filterButton','click',function (e) {
          updateFilter();
        });
      });
    </script>
 
  </body>
</html>

Na początku strony, deklarujemy użycie wtyczki YUI! oraz komponentu dataTable – w ten sposób Grails zadba o to, by nasza strona została wyposażona w linki do odpowiednich skryptów i arkuszy stylów. W znaczniku używam opcjonalnego atrybutu id, jest to spowodowane faktem, że będę się odwoływał do naszej tabeli i muszę wiedzieć jak. Gdybym nie użył id, dostałbym tabelę z unikalnym, losowym identyfikatorem. Nasza tabela wywołuje asynchronicznie metodę listAsJSON kontrolera RestaurantController (o niej za chwilę). Ważne jest, żeby w zdarzeniu onDOMReady powiązać kliknięcie w przycisk Filter z funkcją updateFilter(), w której konstruujemy parametry żądania i wstawiamy je do własności customQueryString naszej tabeli. Następnie obchodzimy jeden bug(?) gui:dataTable, resetujemy pager (na wypadek, gdybyśmy załadowali wynik z mniejszą ilością podstron niż obecna) i przeładowujemy naszą tabelę.

Gotowe :)

Na koniec tylko metoda listAsJSON naszego kontrolera:

def listAsJSON = {
 
        def pagingConfig = [
            max: params.max ?: 15,
            offset: params.offset ?: 0,
            sort: params.sort ?: 'title',
            order: params.order ?: 'asc'
        ]
 
        def resultFilter = {
            or {
                if(params.title && params.title != ''){
                    like("title", "${params.title}%")
                }
                if(params.city && params.city != ''){
                    like("city", "${params.city}%")
                }
            }
        }
 
        def c = Restaurant.createCriteria()
        def list = c.list(pagingConfig, resultFilter)
        def totalRec = list.totalCount
 
        response.setHeader("Cache-Control", "no-store")
        def data = [
            totalRecords: totalRec,
            results: list
        ]
        render data as JSON
    }

Korzystamy tu z dobrodziejstw dwóch ciekawych możliwości oferowanych przez Grails. Pierwszą z nich są Criteria, pozwalające na budowanie filtrów naszego zapytania (za pomocą domknięć mechanizm ten staje się jeszcze atrakcyjniejszy niż jego pierwowzór pochodzący z Hibernate). Każda klasa dziedzinowa posiada możliwość stworzenia obiektu klasy Criteria za pomocą metody createCriteria(). Drugą ciekawostką jest konwerter JSON, ładowany za pomocą importu:

import grails.converters.JSON

Konwerter ten, w locie, zamieni naszą mapę wyników na format JSON, zrozumiały dla naszej tabeli.



Gotowe. Miłego filtrowania :)

]]> http://xis.schowek.net/2009/02/01/grails-datatable-z-filtrem-i-pagerem/feed/ 4 http://xis.schowek.net/2009/01/06/zen-cart-w-zgodzie-z-wamp/ http://xis.schowek.net/2009/01/06/zen-cart-w-zgodzie-z-wamp/#comments Tue, 06 Jan 2009 21:24:05 +0000 xis http://xis.schowek.net/?p=174 Ostatnio miałem okazję wykonać kilka modyfikacji dla platformy sklepowej Zen Cart zainstalowanej na serwerze mojego klienta. Zen Cart to platforma sklepowa oparta o darmowy osCommerce. Istnieje dla niego dość sporo rozszerzeń i wtyczek, ale moje zlecenie było tak specyficzne, że niestety nie obyło się bez potrzeby modyfikacji kodu sklepu (czego, mówiąc szczerze, bardzo starałem się uniknąć).

Wersja produkcyjna sklepu działa pod kontrolą systemu UNIX‘owego, a specyfika zlecenia polegała na tym, że musiałem dokonać kilku poważnych poprawek – co najważniejsze – działając na różnych platformach (czasem musiałem pracować na domowym Linuksie, czasem na Windows).

Przygotowanie środowiska roboczego pod Linuksem zajęło mi naprawdę niewiele czasu; szybko napisałem skrypty automatycznie pobierające bazę danych i synchronizujące pliki kodu z wersją produkcyjną. Gorzej, gdy zacząłem potrzebować możliwości modyfikacji kodu sklepu spod Windows. Muszę przyznać, że był to mój debiut w pisaniu czegokolwiek w php na tym systemie, ale w końcu postanowiłem dać mu szansę. Jako środowiska programistycznego użyłem Aptana Studio (choć mam wrażenie, że wystarczyłby sam Eclipse z PDT), a całość zamierzałem postawić na – znanym mi ze słyszenia – WAMPie. Instalacja WAMP odbyła się bardzo sprawnie, pierwsze Hello World – również bez niespodzianek. Problem jednak zaczął się po instalacji – a jakże – Zen Carta.

Pobrałem zrzut bazy danych i pliki z kodem sklepu i zainstalowałem je w WAMP wykorzystując do tego możliwość tworzenia aliasów.  Okazało się jednak, że instalacja ta nie działa, WAMP serwuje mi tylko komunikaty błędów, albo jakieś krzaki zamiast polskich znaków. Oto lista czynności, które musiałem wykonać, aby zacząć normalnie pracować nad zmianami dla klienta:

Problem 1 – Apache częstuje mnie błędem 500 (Internal Server Error) przy jakimkolwiek odwołaniu.

Problem ten spowodowany był wyłączoną domyślnie obsługą modułu rewrite przez WAMPowego Apacza. Pomogła zwykła edycja httpd.conf i odkomentowanie linijki:

LoadModule rewrite_module modules/mod_rewrite.so

(oczywiście po tym procesie należy wyedytować odpowiednio plik .htacces – zgodnie z potrzebami i ścieżkami)

Problem 2 – Kodowanie polskich znaków bazy danych

Zen Cart niespecjalnie zwraca uwagę na różne możliwości kodowania znaków diakrytycznych bazy danych – na serwerze produkcyjnym była jakaś domyślna konfiguracja i taką też wgrałem u siebie. Niestety, okazało się, że WAMPowe domyślne ustawienie kodowania UTF8 pozwala na wczytanie bazy bez problemów (wpisy są dobrze widoczne z poziomu PhpMyAdmina), jednak sam sklep wyświetla znaki zapytania zamiast polskich literek.  Tu nie obyło się bez modyfikacji kodu Zen Carta i tak  w pliku /includes/init_includes/init_database.php dodałem na końcu pliku linijki:

if( HTTP_SERVER == 'http://localhost' )
    $db->Execute("SET NAMES 'latin2'  COLLATE 'latin2_general_ci'");

i wreszcie zobaczyłem polskie znaki na moim localhost. Powyższy ifcheck wstawiłem po to, by system działał z innymi znakami tylko na konfiguracji roboczej – w wersji produkcyjnej niech zostanie bez zmian. Później i tak usunę te linijki, toteż opatrzyłem je łatwymi do odnalezienia komentarzami. Dodam, że Zen Cart jest tak napisany, że połączenie z bazą danych odbywa się w jeszcze kilku innych miejscach,  należy więc mieć na względzie potencjalną potrzebę dodania powyższych linijek do innych plików, zawierających linijkę:

$db->connect( DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD, DB_DATABASE, USE_PCONNECT, false );

Problem 3 – Puste listy produktów

Kiedy już zażegnałem problemy ‘techniczne’, okazało się, że sklep działa, ale listy produktów są w nim puste. Nie dostawałem komunikatów błędów, ale mimo to strona główna zawierała jedynie boczne sideboksy, a w środku nic. Okazało się, że problemem tutaj był fakt, że domyślna konfiguracja php w WAMP ma wyłączoną opcję Short Tags, co powoduje, że wszelkie template’y zawierające znacznik otwarcia kodu php <? zamiast <?php nie były interpretowane przez parser php. Włączenie powyższej opcji w pliku php.ini spowodowało prawidłowe wyświetlanie produktów.

Po tych poprawkach i restarcie wszystkich usług WAMPa mogłem wreszcie zacząć prace nad sklepem. Wydaje mi się jednak, że – gdybym chciał oprzeć na takiej konfiguracji wersję produkcyją sklepu – musiałbym się jeszcze sporo natrudzić, by uznać to rozwiązanie za stabilne.

]]> http://xis.schowek.net/2009/01/06/zen-cart-w-zgodzie-z-wamp/feed/ 0 http://xis.schowek.net/2008/11/08/java-server-faces-i-parametry-get/ http://xis.schowek.net/2008/11/08/java-server-faces-i-parametry-get/#comments Sat, 08 Nov 2008 16:22:09 +0000 xis http://xis.schowek.net/?p=50 Java Server Faces to całkiem ciekawy framework dla Javy. O jego zaletach dużo by pisać, toteż odsyłam w tym temacie do odpowiednich wpisów w Sieci. JSF ma jednak jedną wadę; dość słabo wspiera przesyłanie parametrów za pomocą metody GET protokołu HTTP. Oto krótki poradnik jak używać parametrów przekazanych za pomocą metody GET do strony obsługiwanej przez Java Server Faces.

Załóżmy, że mamy listę pracowników, z poziomu której możemy podejrzeć konkretnego zatrudnionego. Do obsługi naszej miniaplikacji wykorzystamy zatem dwie  strony employee_list.jsp i employee.jsp. Przyjmijmy także, że chcielibyśmy, aby dostęp do szczegółów dot. pracownika możliwy był po wprowadzeniu adresu np. http://localhost:8080/company/employee.jsf?e=10. Naszą aplikację zasili ziarno zarządzane (managed bean) CompanyController, którą wyposażamy we własność selectedEmployeeId i własność selectedEmployee zawierającą obiekt wskazanego pracownika:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

package net.schowek.jsf.ui;   public class CompanyController { @EJB CompanyServiceLocal companyService;   private DataModel empDataModel; private Long selectedEmployeeId; private Employee selectedEmployee;   public DataModel getAllEmployees() { empDataModel = new ListDataModel(); empDataModel.setWrappedData( companyService.findAll() ); return empDataModel; }   public Employee getSelectedEmployee() { if (selectedEmployee == null) { selectedEmployee = (Employee) companyService.findById( selectedEmployeeId ); } return selectedEmployee; }   public void setSelectedEmployee( Employee selectedEmployee ) { this.selectedEmployee = selectedEmployee; }   public Long getSelectedEmployeeId() { return selectedEmployeeId; }   public void setSelectedEmployeeId( Long selectedEmployeeId ) { this.selectedEmployeeId = selectedEmployeeId; } }

Wygląda to więc dość standardowo, tylko posługujemy sie tą tajemniczą własnością selectedEmployeeId. I skąd nasz CompanyController ma wiedzieć, że w tejże własności ma znaleźć się parametr przekazany w metodzie GET pod zmienną ‘e‘?

Zdefiniujemy to pliku faces-config.xml:

<managed-bean>
    <managed-bean-name>company</managed-bean-name>
    <managed-bean-class>net.schowek.jsf.ui.CompanyController</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
    <managed-property>
        <property-name>selectedEmployeeId</property-name>
        <value>#{param.e}</value>
    </managed-property>
</managed-bean>

Oraz nasze pliczki stron:

Lista pracowników:

<!-- employee_list.jsp -->
<f:view>
    <h:form>
        <h:datatable var="employee" value="#{company.allEmployees}">
            <h:column>
                <h:outputtext value="#{employee.id}" />
            </h:column>
            <h:column>
                <h:outputtext value="#{employee.name}" />
            </h:column>
            <h:column>
                <h:outputlink value="employee.jsf">
                    <f:verbatim>Szczegóły</f:verbatim>
                    <f:param value="#{employee.id}" name="e" />
                </h:outputlink>
            </h:column>
        </h:datatable>
    </h:form>
</f:view>

…, karta pracownika…

<!-- employee.jsp -->
<f:view>
    <h:form>
        <h2>Szczegóły pracownika #<h:outputText value="#company.selectedEmployee.id"/></h2>
        <div>
            <span>Imię i nazwisko:</span>
            <span><h:outputText value="#company.selectedEmployee.name"/></span>
        </div>
        <div>
            <span>Stanowisko:</span>
            <span><h:outputText value="#company.selectedEmployee.position"/></span>
        </div>
        <div>
            <span>Dodatkowe informacje:</span>
            <div><h:outputText value="#company.selectedEmployee.comments"/></div>
        </div>
    </h:form>
</f:view>

Takie rozwiązanie ma jednak dość poważną wadę, bowiem wspiera jedynie ziarna zarządzane, których zasięg (scope) dotyczy żądania. Własności ziaren zarządzanych deklarowanych w pliku faces-config.xml muszą mieć czas życia co najmniej taki jak czas życia samego ziarna, toteż #{param}, który żyje tylko wraz z żądaniem ogranicza zasięg całego ziarna. Często jednak zdarza się, że potrzebujemy ziarna żyjącego przez całą sesję, wtedy nie możemy skorzystać z własności deklarowanej w faces-config.xml. Możemy jednak, zamiast oczekiwać wstrzyknięcia wartości naszej własności przez JSF, sami pobrać wartość parametru żądania.

W tym celu usuwamy z pliku faces-config.xml deklarację parametru pozostawiając:

<managed-bean>
    <managed-bean-name>company</managed-bean-name>
    <managed-bean-class>net.schowek.jsf.ui.CompanyController</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

Modyfikujemy tez nasze ziarno usuwając własność selectedEmployeeId wraz z getterem i setterem i zmieniając metodę getSelectedEmployee():

public Employee getSelectedEmployee()
{
  Map<String, String> reqParams = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap();
  String eId = reqParams.get( "e" );
  Long selectedEmployeeId = Long.parseLong( eId );
  if (selectedEmployee == null)
  {
    selectedEmployee = (Employee) companyService.findById( selectedEmployeeId );
  }
  return selectedEmployee;
}

Od tej pory ziarno o czasie życia sesji również potrafi obsługiwać parametry GET, a my możemy dodawać do zakładek odnośniki do kart konkretnych pracowników :)

]]> http://xis.schowek.net/2008/11/08/java-server-faces-i-parametry-get/feed/ 2 http://xis.schowek.net/2008/11/04/balagan-w-mrowisku/ http://xis.schowek.net/2008/11/04/balagan-w-mrowisku/#comments Tue, 04 Nov 2008 08:54:24 +0000 xis http://xis.schowek.net/2008/11/04/balagan-w-mrowisku/ Dość długo nic nie pisałem, szczerze mówiąc zastanawiałem się, czy nie przestać całkowicie (jak się okazuje, strasznie trudno pisać o tym, co możnaby w tym czasie robić ;) ), ale postanowiłem coś jednak naskrobać i dalej prowadzić ten swój zapiśnik. Nie będę chyba jednak publikował wpisów zbyt często, bo postanowiłem już całkowicie sprowadzić tego bloga do roli swego rodzaju notatnika zawierającego po prostu rzeczy do zapamiętania.

Dziś o pewnym narzędziu, z którym życie programisty Java staje się łatwiejsze – Ant.

Ant to – jak pewnie każdy Javowiec wie – doskonałe narzędzie upraszczające nie tylko proces budowania projektów, ale pomagające zautomatyzować każdą rutynową operację. Wachlarz instrukcji, które potrafi on wykonać jest ogromny i stale się powiększa.

Ostatnio miałem okazję budować projekt, który zależał od kilku innych podprojektów, których z kolei wynikami były różne typy archiwów (JAR/WAR). Całość (projekt główny) była pakietem EAR zawierającym wspomniane wcześniej archiwa. Z poziomu mojego ulubionego Eclipse można oczywiście wyklikać eksport owych składników do projektu docelowego, ale wykonywanie tego przy każdej próbie sprawdzenia efektów swojej pracy było dość uciążliwe. Na szczęście Eclipse jest doskonale zintegrowany z Antem, toteż przygotowanie pliku budującego dla moich projektów trwało dosłownie chwilę. Ant dysponuje również instrukcją ‘ant’ pozwalającą na wykonanie innego pliku budującego z poziomu pliku głównego. To idealne rozwiązanie dla mojej sytuacji z podprojektami.

<property name="ejbjar.dir" value="${basedir}/../MyEJBModule"/>
<property name="webmodule.dir" value="${basedir}/../MyWEBModule"/>        
<target name="preparecomponents">
  <ant antfile="build.xml" dir="${ejbjar.dir}"/>
  <ant antfile="build.xml" dir="${webmodule.dir}"/>
</target>

Pojawił się jednak pewien problem, otóż tak wykonywane skrypty Ant’a posiadały dość dziwne własności (properties). Okazało się, że dziedziczą one po projekcie głównym i tak najczęściej używane przeze mnie własności jak np. project.distname, czy basedir miały wartości zdefiniowane w projekcie głównym, a nie te, których definicja występowała u nich samych, co oczywiście powodowało błędy przy budowaniu i ogólną porażkę. Rozwiązaniem może tu być zmiana nazw własności na unikalne dla każdego z projektów, ale to oczywiście nie jest najelegantsze rozwiązanie, pomijając już jego sensowność.

Na szczęście Ant zabezpiecza nas przed tym dodając atrybut inheritall, pozwalający na zbudowanie zupełnie nowego środowiska dla każdego poszczególnego skryptu wykonywanego z poziomu skryptu głównego.

<target name="preparecomponents">
  <ant antfile="build.xml" dir="${ejbjar.dir}" inheritall="false"/>
  <ant antfile="build.xml" dir="${webmodule.dir}" inheritall="false"/>
</target>

W ten sposób każdy z komponentów zostanie zbudowany tak, jakbyśmy wykonali osobno każdy ze skryptów budowania. Warto zanotować, że w elemencie ant można zagnieżdżać elementy property i przekazywać je do wykonywanego skryptu, zatem komunikacja skryptu głównego z komponentami jest również możliwa.

]]> http://xis.schowek.net/2008/11/04/balagan-w-mrowisku/feed/ 0