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.

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.

set OSQL="c:\\Program Files\\MS SQL Server\\80\\Tools\\Binn\\osql.exe"
%OSQL% -E -d moja_baza < skrypt.sql

…wczytał, i owszem, moje wypociny w SQL, ale… zupełnie zniekształcił polskie znaki. Dostałem w ich miejsce jakieś dziwaczne krzaki, przypominające czasy źle skonfigurowanych Linuksów ;)
Nie pomaga w tej sytuacji zmiana kodowania pliku wejściowego (skrypt.sql), ani cudaczne opcje, z którymi można uruchomić ‘osql’.
Okazuje się, że winą za ten stan rzeczy obarczać możemy… windowsowy wiersz poleceń. Otóż ‘cmd.exe’, w środowisku którego wykonywane są wszystkie skryptu batchowe w Windows, pracuje używając innego kodowania znaków niż reszta systemu. Dlaczego? Nie mam pojęcia, pewnie ze względu na kompatybilność z DOS’em.
Sposobem obejścia tego problemu jest rezygnacja z windowsowej możliwości przekierowania strumieni na wejścia/wyjścia programów (bo to właśnie tam powstaje nieszczęsna konwersja znaków do DOS’owych krzaków). Na szczęście znalazła się w opcjach ‘osql’ (czyli trochę jednak skłamałem pisząc kilka linijek wyżej, że ‘osql’ nie miał pomocnej w tej sytuacji opcji ;) ) możliwość wykonania polecenia z plikiem zadanym na wejściu.
Rozwiązaniem jest zapisanie skryptu w kodowaniu, którego używa MS SQL Server (u mnie UTF-8) i wykonanie poniższego poleconka (uprzednio oczywiście ustawiając zmienną OSQL):

%OSQL% -E -d moja_baza -i skrypt.sql

Od tej pory znaki ze skryptu wędrują nienaruszone prosto do mojej bazy :)

Znalazłem jednak ostatnio kilka sposobów by sobie z tą sytuacją poradzić. Pierwszym z rozwiązań jest oczywiście CygWin, dzięki któremu można już cieszyć się dobrodziejstwami SH w windows. Teraz znalazłem też i sam konkretny emulator terminala – otwarty i dużo mniej toporny.
Z tymi narzędziami praca w tym, niezbyt lubianym przeze mnie, systemie staje się od razu mniej męcząca :)

dcop konqueror KonquerorIface createNewWindow http://moja.strona.net

Generalnie reklamować DCOP nie trzeba (może warto tylko dodać, że w KDE 4 będziemy mieli jeszcze lepiej za sprawą nowocześniejszego i jeszcze bardziej powszechnego D-Bus, który nie jest ograniczony tylko do KDE).

Było jednak coś, co nie pozwalało mi wykorzystywać dobrodziejstw polecenia dcop w pełni. O ile przekazywanie argumentów numerycznych było proste (wystarczy wpisać liczbę), argumentów tekstowych dość intuicyjne (stringi piszemy w apostrofach jeśli zawierają kilka słów, lub niekoniecznie z nimi, jeśli to tylko jedno słowo), o tyle przekazanie argumentu QStringList było dla mnie czarną magią.
Jak to się robi? Kombinowałem ze wszystkimi znanymi mi sposobami i nic…

Dopiero Michelle sprawiła, że zająłem się tym nieco konkretniej. Michelle używa Firefoksa, a – jak wszyscy wiemy – jego wbudowany czytnik kanałów RSS jest, delikatnie mówiąc, dość ubogi. Więc jak tylko zaraziłem Ją RSSoManią, natychmiast pożałowałem, bo przygniotła mnie sterta pytań ‘A jak ustawić, żeby…’ ;) Na pomoc przyszedł mi Akregator – niesamowity czytnik. Wygodny, konfigurowalny, szybki i… KDE’owy :) Pozostał tylko jeden problem. Jak przekazać Akregatorowi informację o URL kanału z poziomu Firefoksa? Na szczęście FF ma możliwość wykonania komendy z adresem kanału. No, ale tu właśnie pojawił się problem. Interfejs DCOP Akregatora pozwala wprawdzie na dodanie do niego kolejnego URL kanału RSS, jednak postać polecenia jest taka:

xis@hedera ~ $ dcop akregator AkregatorIface
QCStringList interfaces()
QCStringList functions()
void openStandardFeedList()
void fetchFeedUrl(QString)
void fetchAllFeeds()
void saveSettings()
void addFeedsToGroup(QStringList,QString)
void exportFile(KURL url)
void addFeed()

Łatwo się domyślić, że pierwszy parametr to lista URLi, a drugi to grupa, do jakiej mają być kanały dodane. I jak tę listę przekazać? Ano tak:

#!/bin/bash
dcop akregator AkregatorIface addFeedsToGroup [ $1 ] Michelle

Taki skrypcik zapisujemy pod postacią np. ‘addrss’, dajemy prawa wykonania, umieszczamy gdzieć na naszej $PATH i już możemy konfigurować Firefoksa wskazując mu komendę addrss do wykonania przy dodawaniu kanału informacyjnego.

Działa super :)

Dodam tylko, że aby przekazać w QStringList większą ilość stringów, wystarczy oddzielić je przecinkami.

Większość forów internetowych – ze względów bezpieczeństwa – nie zezwala na umieszczanie w avatarze, czy sygnaturce obrazka z rozszerzeniem ‘php’, i nic w tym dziwnego.
Ze względu na to, że serwer, na którym trzymam skrypt nie daje mi możliwości modyfikacji konfiguracji (nie mogę przekonfigurować apacza, by ‘interpretował’ np. pliki o rozszerzeniu ‘png’ jak skrypty php) nie mogę po prostu zmienić rozszerzenia pliku z kodem skryptu.
Pomocna okazała się technologia .htaccess. Jesli serwer wspiera ten mechanizm, wystarczy w katalogu, w którym znajduje się skrypt umieścić pliczek .htaccess, a w nim:

Options +FollowSymlinks
RewriteEngine on
RewriteRule ^ja.png$ ee.php [nc]

Od tej pory mogę wskazywać na mój skrypt adresem http://schowek.net/stuff/ja.png. Więcej o samym .htaccess tutaj i tutaj.

Narzędzia -> Opcje -> OpenOffice.org -> Czcionki

Następnie zaznaczyć checkbox Zastosuj tabelę zmian, a w poniższej tabeli wprowadzić zmianę czcionki Andale Sans UI na np. Arial. Ważne jest, żeby wprowadzić nazwę czcionki Andale Sans UI nawet jeśli nie było jej na liście czcionek.

Po tej operacji wszystkie aplikacje OpenOffice.org będą już wyglądały tak ładnie jak inne aplikacje naszego pulpitu :)

Writer przed liftingiem

Writer po liftingu

Przy okazji warto też wyłączyć antialiasing czcionek edytowanych dokumentów; z

Narzędzia -> Opcje -> OpenOffice.org -> Widok

odznaczyć checkbox Wygładzanie czcionek ekranowych (lub ustawić dolny pułap wygładzania na np. 18 pikseli). Operacja ta sprawia, że praca z dokumentami staje się wygodniejsza, bo Writer działa dużo szybciej nie ‘tracąc’ czasu na wygładzanie czcionek.

Kiedyś bardzo drażnił nierówny hinting czcionek i tak np. w Fedorze czcionki wyglądały bardzo ładnie, byly równe i gładkie, podczas gdy np. w Gentoo domyślne fonty były dziwnie koślawe. Pomocna wtedy okazywała się łatka do Xft, która sprawiała, że hinting fontów był dużo równiejszy. Dziś łatka ta jest niepotrzebna, bo chyba wszystkie wersje Xorg stosują poprawny hinting czcionek. Mój linuksowy desktop wyglądał istnie jak Macintosh. Oczywiście całej sprawie ukryty był pewien haczyk – fonty były ładne, ale pod warunkiem używania antialiasingu. Kiedy tylko wyłączałem wygładzanie, mój ekran wypełniała cała banda koślawych i poszarpanych liter. Nie przeszkadzało mi to dopóki uzywałem monitora CRT, ale zaczęło denerwować gdy kupiłem matrycę LCD. Czcionki wygładzane nie podobały mi się zbytnio na nowym monitorze, dlatego zdecydowałem się używać wszędzie czcionek Helvetica firmy Adobe, co pozwoliło mi na wyłączenie antialiasingu. Było jednak coś, co strasznie mnie drażniło – pytanie ‘Jak to jest, że w Windows wszystkie czcionki tak ładnie wyglądają, a moje KDE jest skazane na Helveticę?’. Udało mi się jednak zaradzić i temu problemowi. Mimo, że artykuł, który znalazłem w Sieci jest dość leciwy, jego treść i rady, jakie niesie są wciąż aktualne. Po zastosowaniu się do rad autora i zrekompilowaniu pakietu freetype mogę cieszyć się równymi czcionkami czy to z antialiasingiem, czy bez niego. Ponadto, postanowiłem skorzystać z opcji włączania antialiasingu przy czcionkach większych niż 10 pikseli, dzięki czemu teraz wygładzane są tylko te duże czcionki (np. nagłówki stron WWW).

Przy okazji poruszania tematu czcionek załączam plik z bitmapowym fontem Console, dzięki któremu mój emulator terminala wygląda naprawdę fajnie (używam go też w edytorach tekstowych).