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?

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.

Przyznam, że raczej sceptycznie reaguję na różne ‘liberalne’ języki programowania, np. fakt, że jakąś operację można wykonać używając różnych konstrukcji języka (bo wg mnie zaciemnia to nieco obraz samego kodu i utrudnia jego pielęgnację), albo dynamiczcne typowanie (zawsze przeklinałem PHP za tę ‘przypadłość’), jednak dałem Groovy’emu szansę, za jego główną zaletę: pełną kompatybilność z Javą – Groovy jest de facto wykonywany przez maszynę wirtualną Javy, więc kompatybilność ta jest oczywista.

Umówmy się – należę do tych bardziej konserwatywnych programistów wierzących w ‘twardą’ składnię, a w Groovy nie umiem (jeszcze) nic poza „Hello World”, toteż bardzo zależało mi na frameworku, w którym będę mógł wykorzystać już istniejące ziarenka Javy.  Samego Groovy’ego też chętnie zgłębię, ale najpierw chcę zobaczyć co mogę zrobić z Grailsami wykorzystując istniejący już kod Javy.

Grails – jak RoR, czy Symfony – posiada własny mechanizm mapowania obiektowo-relacyjnego (gdzieś tam głęboko napędzany przez Hibernate), zwany GORM, pozwalający na mapowanie klas Groovy’ego z bazą danych. Ja jednak, przez założenie, chcę mapować ziarna encji Hibernate napisane w Javie. Grails pozwala na to bez problemów, kilka prostych czynności i już możemy wykorzystać przygotowane wcześniej encje w Grails.

No, może nie całkiem bez problemów.

Aby zmapować klasy encji wystarczy, zgodnie z opisem na stronie Grails, wyedytować plik DataSource.groovy, dodać mapowanie w hibernate.cfg.xml i wreszcie skopiować swoje klasy javy do katalogu src/java. Po wykonaniu tych czynności możemy już wygenerować na podstawie encji nowy kontroler i widok, wklepując w konsoli:

grails generate-all pelna.nazwa.naszej.Klasy

Grails wygeneruje dla nas wszystkie niezbędne klasy kontrolerów (w języku Groovy, rzecz jasna), elementy widoku (strony GSP), słowem mamy już cały CRUD. Problem jednak pojawia się w przypadku, gdy nasza encja wyposażona jest w klucz złożony, a schemat naszej bazy danych – jak w moim przypadku –  nie może zostać zmodyfikowany, bo jest wykorzystywany przez inne programy.

Grails teoretycznie pozwoli na mapowanie takich encji, wygeneruje też dla nich kontrolery i pliki widoków, jednak nie bedą one działały. Rozważmy poniższy przypadek.

Mamy encję Produkt (mapowaną  na tabelę „PRODUKTY”), encję Cennik (mapowaną na tabelę „CENNIKI”) i encję Cena (tabela „CENY”) . NetBeans, na podstawie istniejącego schematu bazy danych, wygenerował mi takie klasy (po drobnej korekcie nazw własności):

package net.schowek.grailsapp;
 
// importy
 
@Entity
@Table(name = "PRODUKTY")
@NamedQueries({@NamedQuery(name = "Produkt.findAll", query = "SELECT p FROM Produkt p")})
public class Produkt implements Serializable {
    private static final long serialVersionUID = 1L;
 
    @Id
    @Basic(optional = false)
    @Column(name = "pr_id")
    private Integer id;
 
    @Basic(optional = false)
    @Column(name = "pr_nazwa")
    private String nazwa;
 
    @Column(name = "pr_opis")
    private String opis;
 
    public Produkt() {
    }
 
    public Produkt(Integer prId) {
        this.id = prId;
    }
 
    // gettery i settery
 
    @Override
    public String toString() {
        return getNazwa();
    }
}

package net.schowek.grailsapp;
 
// importy
 
@Entity
@Table(name = "CENNIKI")
@NamedQueries({@NamedQuery(name = "Cennik.findAll", query = "SELECT c FROM Cennik c")})
public class Cennik implements Serializable {
    private static final long serialVersionUID = 1L;
 
    @Id
    @Basic(optional = false)
    @Column(name = "cn_id")
    private Integer id;
 
    @Column(name = "cn_nazwa")
    private String nazwa;
 
    public Cennik() {
    }
 
    public Cennik(Integer cnId) {
        this.id = cnId;
    }
 
    // gettery i settery
 
    @Override
    public String toString() {
        return getNazwa();
    }
}

package net.schowek.grailsapp;
 
// importy
 
@Entity
@Table(name = "CENY")
@NamedQueries({@NamedQuery(name = "Cena.findAll", query = "SELECT c FROM Cena c")})
public class Cena implements Serializable {
    private static final long serialVersionUID = 1L;
 
    @EmbeddedId
    private CenaPK id;
 
    @JoinColumn( name = "ce_pr_id", referencedColumnName = "pr_id", insertable = false, updatable = false  )
    @ManyToOne
    private Produkt produkt;
 
    @JoinColumn( name = "ce_cn_id", referencedColumnName = "cn_id", insertable = false, updatable = false  )
    @ManyToOne
    private Cennik cennik;
 
    @Column(name = "ce_cena")
    private BigDecimal cena;
 
    public Cena() {
    }
 
    public Cena(CenaPK cenaPK) {
        this.id = cenaPK;
    }
 
    // gettery i settery
 
    @Override
    public String toString() {
        return getId().toString();
    }
}

I wreszcie klasa określająca nasz klucz złożony:

package net.schowek.grailsapp;
 
// importy
 
@Embeddable
public class CenaPK implements Serializable {
 
    @Basic(optional = false)
    @Column(name = "ce_pr_id")
    private int cePrId;
 
    @Basic(optional = false)
    @Column(name = "ce_cn_id")
    private int ceCnId;
 
    public CenaPK() {
    }
 
    public CenaPK(int cePrId, int ceCnId) {
        this.cePrId = cePrId;
        this.ceCnId = ceCnId;
    }
 
    public int getCePrId() {
        return cePrId;
    }
 
    public void setCePrId(int cePrId) {
        this.cePrId = cePrId;
    }
 
    public int getCeCnId() {
        return ceCnId;
    }
 
    public void setCeCnId(int ceCnId) {
        this.ceCnId = ceCnId;
    }
 
    @Override
    public String toString() {
        return "net.schowek.grailsapp.CenaPK[cePrId=" + cePrId + ", ceCnId=" + ceCnId + "]";
    }
 
}

Tak przygotowanesą podstawą wygenerowanej aplikacji.  Po uruchomieniu aplikacji za pomocą komendy grails run-app mogę już eksplorować zasoby cen i produktów. Problem jednak zaczyna się, gdy chcę przejrzeć listę cen. Już na liście (http://localhost:8080/GrailsApp/cena/list) widać, że odnośniki do rekordów cen nie przypominają standardowych odnośników do rekordów tabel o prostych kluczach. Przykładowy link do ceny wyglądał tak:

http://localhost:8080/GrailsAppl/cena/show/net.schowek.grailsapp.CenaPK%5BcePrId%3D63%2C+ceCnId%3D2%5D

a strona, którą można pod nim zobaczyć wygląda tak:

Jak widać, Grails w miejsce id, podstawia wartość obiektu klasy CenaPK, a ten reprezentowany jest przez swoją metodę toString().  Po odwołaniu się do serwera i zapytaniu o cenę o podanym kluczu, serwer – co oczywiste – częstuje nas wyjątkiem.

Oto prosty sposób, w jaki można temu zaradzić (zakładając, że klucz złożony składa się z pól typu numerycznego).

Przede wszystkim, zmieniłem kod klasy CenaPK na taki (zmieniłem toString() i dodałem jeden konstruktor):

    public static final String KEY_SEPARATOR="_";
 
    @Override
    public String toString() {
        return cePrId+KEY_SEPARATOR+ceCnId;
    }
 
    public CenaPK(String k) {
        String[] keys = k.split( KEY_SEPARATOR );
        this.cePrId = Integer.parseInt(keys[0]);
        this.ceCnId = Integer.parseInt(keys[1]);
    }

Jak widzisz, połączyłem w jeden string dwa klucze oddzielone od siebie separatorem. Oznacza to, że ponowne wygenerowanie widoków komendą:

grails generate-views net.schowek.grailsapp.Cena

poskutkuje nową listą cen, zawierającą odnośniki do rekordów podobne do tych:

http://localhost:8080/GrailsAppl/cena/show/63_2

Aby wszystko grało, musiałem jeszcze przerobić kontroler cen (plik CenaController.groovy w katalogu controllers/) i zmienić wszystkie linie ładujące pojedynczy rekord ceny z

def cenaInstance = Cena.get( params.id )

na

def cenaInstance = Cena.get( new CenaPK(params.id) )

Od tej pory mogłem się już cieszyć działającą aplikacją obsługującą klucze złożone.

Aha, separatorem klucza może być w zasadzie dowolny znak, jednak są tu wyjątki – np. nie zadziała na pewno slash, ponieważ jest on interpretowany przez UrlMappera grails. Warto zatem sprawdzić co zadziała, a co nie.

• JUnit – Pragmatyczne testy jednostkowe w Javie
• JAVA – Tworzenie aplikacji sieciowych za pomocą Springa, Hibernate i Eclipse
• Eclipse Web Tools Platform – Tworzenie aplikacji WWW w języku Java
• J2EE – Wzorce projektowe
• Enterprise Java Beans 3.0 (którą dostałem nieco wcześniej, ale jest mi szczególnie bliska ze względu na ostatnie tą platformą zainteresowanie)

Z takim arsenałem lektur mam teraz zajęć na zimowe wieczory pod dostatkiem.  W tej jednak chwili prawdziwym dylematem będzie dla mnie pytanie „Od czego zacząć?” gdy zasiądę na kanapie z filiżanką kawy ;)

Muszę się zwierzyć, że książki papierowe to mój ulubiony sposób zdobywania wiedzy w zakresie programowania, ale też niestety najbardziej zaniedbany. W epoce Google’a trudno jest ‘marnować’ czas na wyszukiwanie odpowiednich pozycji książkowych, podczas gdy łatwo sobie coś znaleźć w Sieci ‘na szybko’. Ja także stałem się ofiarą czegoś w rodzaju fast-foodu w dziedzinie zdobywania wiedzy (szybkie wyszukiwanie, krótka lektura wiki, krótka lektura tutoriala, krótkie ‘Hello World’ i już ‘znam’ techonlogię) i trochę tego żałuję. Mam teraz idealną okazję, by nadrobić zaległości, pozagłębiać się trochę w szczegóły i – wreszcie – poznać polskie nazwy niektórych terminów, które stosuję w praktyce od dłuższego czasu (kolejna wada ‘fast-foodów wiedzy’ to taka, że większość pozyskiwanych informacji przychodzi w języku angielskim i nie zna się jej oficjalnych tłumaczeń).

Dodatkową niespodzianką, jaka zawitała pod Świąteczne drzewko, była koszulka z bardzo fajnie wykonanym napisikiem (za którą dziękuję Adze i Zbigowi) ;)

Wesołych Świąt!

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 :)

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.

Przykładowa sytuacja:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package net.schowek.ws.server;             
 
public class Foo 
{ 
    private int bar;         
 
    public int getBar() 
    { 
        return bar; 
    }           
 
    public void setBar(int bar) 
    { 
         this.bar = bar; 
    }              
 
    public void blah() 
    { 
        System.out.println("BLAH: "+bar); 
    } 
}

Niech nasza klasa serwisu wygląda tak:

1
2
3
4
5
6
7
8
9
10
11

package net.schowek.ws.server;        
 
public class FooService 
{ 
    public Foo getFoo(int b) 
    { 
        Foo f = new Foo(); 
        f.setBar(b) 
        return f; 
    } 
}

Jeśli nasza usługa udostępni obiekt klasy Foo, to WSDL2Java wygeneruje kod w pakiecie np. net.schowek.ws.client, w którym zdefiniowana będzie klasa Foo, ale bez metody blah() (wygeneruje tylko gettery i settery).
A szkoda, bo całą funcjonalność prawdopodobnie będziemy musieli klientowi implementować od nowa.
Spróbujmy więc zaplanować inną architekturę. Niech nasza klasa Foo powędruje do pakietu net.schowek.ws.common, a pakiet serwera niech zaimplementuje jedynie FooService, zwracającą obiekt klasy Foo w pakiecie wspólnym. Byłoby super, gdyby WSDL2Java wygenerował nam teraz kod, który również dziedziczyłby po pakiecie net.schowek.ws.common.
Jak tego dokonać? No właśnie.
Twórcy Axis’a, w którego skład wchodzi WSDL2Java pomyśleli o tym i pozwolili użytkownikowi na skonstruowanie własnych generatorów kodu. Wystarczy zaimplementować własną klasę WSDL2Java:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package net.schowek.ws.tools;        
 
public class MyWSDL2Java extends WSDL2Java 
{ 
    public MyWSDL2Java()  { }            
 
    protected Parser createParser() 
    { 
        return new MyEmitter(); 
    }        
 
    public static void main(String args[]) 
    { 
        MyWSDL2Java w2j = new MyWSDL2Java(); 
        w2j.run(args); 
    } 
}

Własną klasę emitera:

1
2
3
4
5
6
7
8
9
10
11

package net.schowek.ws.tools;        
 
public class MyEmitter extends Emitter 
{ 
    public MyEmitter() 
    { 
        MyGeneratorFactory factory = new MyGeneratorFactory(); 
        setFactory(factory); 
        factory.setEmitter(this); 
    } 
}

Własną fabrykę generatorów:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package net.schowek.ws.tools;        
 
public class MyGeneratorFactory extends JavaGeneratorFactory 
{ 
    public Generator getGenerator(TypeEntry type, SymbolTable symbolTable) 
    { 
        if (include(type.getQName())) 
        { 
            return new MyGeneratorWriter(emitter, type, symbolTable); 
        } 
        else 
        { 
            return new NoopGenerator(); 
        } 
    } 
}

… i wreszcie – sam generator.

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

package net.schowek.ws.tools;   
 
public class MyGeneratorWriter extends JavaTypeWriter 
{ 
    public MyGeneratorWriter( Emitter e, TypeEntry t, SymbolTable s ) 
    { 
        super( e, t, s ); 
    }   
 
    public JavaWriter getBeanWriter( Emitter emitter, TypeEntry type, TypeEntry base ) 
    { 
        Vector elements = type.getContainedElements(); 
        Vector attributes = type.getContainedAttributes(); 
        Boolean isComplexFault = (Boolean)type.getDynamicVar( 
                              JavaGeneratorFactory.COMPLEX_TYPE_FAULT );   
 
        if( ( isComplexFault != null ) && isComplexFault.booleanValue() ) 
        { 
            return super.getBeanWriter( emitter, type, base ); 
        }   
 
        return new MyBeanWriter( emitter, type, elements, base, attributes, 
            getBeanHelperWriter( emitter, type, elements, base, attributes, false ) ); 
    } 
}

i writer, czyli klasę odpowiedzialną za generowanie odpowiedniego kodu (w tym przypadku – klasy)

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

package net.schowek.ws.tools;        
 
public class MyBeanWriter extends JavaBeanWriter 
{ 
    protected MyBeanWriter( Emitter e, TypeEntry t1, Vector v1, 
                            TypeEntry t2, Vector v2, JavaWriter w ) 
    { 
        super( e, t1, v1, t2, v2, w ); 
        this.enableSimpleConstructors = false; 
        this.enableDefaultConstructor = true; 
        this.enableFullConstructor = false; 
        this.enableMemberFields = false; 
        this.enableGetters = false; 
        this.enableSetters = false; 
    }            
 
    protected String getImplementsText() 
    { 
        String s = " extends net.schowek.ws.common." 
                 + this.getClassName()+ " " 
                 + super.getImplementsText(); 
        return s; 
    }        
 
    protected void writeAccessMethods() 
    { 
        pw.println("    public " 
                 + className 
                 + "( net.schowek.ws.common." 
                 + className 
                 + " old ) { " );        
 
        for (int i = 0; i < names.size(); i += 2) 
        { 
            String variable = (String) names.get(i + 1); 
            String typeName = (String) names.get(i); 
            String var = Utils.capitalizeFirstChar(variable) 
            String getter = "";        
 
            if( typeName.equals( "boolean" )) 
            { 
                getter = "old.is" + var + "()"; 
            } 
            else 
            { 
                getter = "old.get" + var + "()"; 
            }        
 
            pw.println("           this.set" + var + "( "+getter+" );");        
 
            if (i >= names.size() - 2) 
            { 
                break; 
            } 
        }        
 
        pw.println("    }"); 
        pw.println(); 
        super.writeAccessMethods(); 
    } 
}

Jak widać w konstruktorze klasy MyBeanWriter, generatory są całkiem fajnie konfigurowalne, dzięki czemu nasz kod może wyglądać naprawdę różnie. Żeby ‘wstrzyknąć’ do wygenerowanego kodu informację o dziedziczeniu z pakietu wspólnego użyłem przesłonięcia metody getImplementsText() (skorzystałem z tego, że informacje o dziedziczeniu jest umieszczanie w Javie zaraz przed deklaracją i implementowaniu interfejsu) – ta metoda wywoła się na pewno, bo WSDL2Java już tak ma ;)
Ze względu na fakt, że nasza wygenerowana klasa będzie dziedziczyć po klasie z pakietu wspólnego, nie ma potrzeby deklarowania jej własności, dlatego wyłączam enableMemberFields (należy jednak pamiętać, że pierwowzór klasy Foo w pakiecie common musi mieć własności o dostępie protected, a nie private). Ponadto, skoro włączyłem już enableDefaultConstructor, to postanowiłem wykonać też metodę, która wygeneruje mi konstruktor kopiujący z obiektu klasy nadrzędnej. W ten sposób zapewniłem możliwość rzutowania moich klas klienta i serwera w obie strony (w końcu mają być takie same, prawda?). Kod można oczywiście poprawić tak, by nazwę pakietu wspólnego dało się podawać np. jako opcję przy uruchomieniu, ale najważniejsze, że robi to co chciałem i tak jest fajnie :)