niedziela, 5 kwietnia 2009

Konferowanie, konferowanie i po konferowaniu...

Sława!

W minioną sobotę miałem niewątpliwą przyjemność uczestniczenia w naszej, kochanej, lokalnej konferencji Java4People (wiadomo, darmowy obiad ;)). Zaczęło się miło, bo ochrzanem od Leszka za spóźnianie się (oj, ledwie ze trzy minutki ;)), na szczęście potem było lepiej. O naprawdę wysokim poziomie prelegentów niech świadczy fakt, że takiemu "byłemu" programiście Javy, co to szybko się nudzi i mało rozumie, jak ja, ani razu się nie ziewnęło ;) Ale może po kolei.

Na pierwszy ogień poszedł Paweł Szulc z prezentacją na temat testowania EJB. To co mnie ucieszyło w niej szczególnie, to przede wszystkim pokazanie, że testowanie własnego kodu nie gryzie, i nawet w "takim" EJB da się to prosto zrobić. A dlaczego mnie to ucieszyło? Bo może dzięki temu będę ja, lub ktoś mi podobny mniej roboty ;) Wbrew ogólnej opinii robienie reopen na zadaniach w jirze mnie nie jara szczególnie ;)

Drugim rzutem, przyatakował Waldek Kot o kometach i miasteczkach w Normandii, coś nowego, interesująco się zapowiadającego i wraz z upowszechnianiem się technologii "odwrotnego ajaksu" czuję nosem kolejne wyzwania (no, może wyzwanka) przy testach funkcjonalnych aplikacji sieciowych.

Po nim chwila wytchnienia, zużyta na relaksujący spacerek do cukierni, aby coś przekąsić (ha! nie lubię pizzy i wolę Pepsi, nic dziwnego, że już nie pracuję jako programista ;)), a po przerwie kolejna fala prelegentów.

Zaczął ją Andrzej Śliwa rzucając parę słów o gitach. Ciekawe, ciekawe, w święta chyba sobie popróbuję trochę, bo możliwości to to ma fajnych parę.

Następnie Jacek Laskowski jak zwykle dał popis, z niezwykłym polotem prezentując atrakcyjne szynki. Aż szkoda, że sieć to Zło ;), bo korci rzucić wszystko i zostać fanboyem Grailsów, tymbardziej, że, jak pokazał Szanowny Prowadzący, niespodziewane wyjątki, błędy i wypaczenia nie są czymś strasznym... ;)

Ostatnim próbującym uśpić więcej niż jednego prelegenta (tak, tak, trudno w to uwierzyć, ale Jackowi L. się jednego uśpić, i obudzić, udało ;)) odważnym był Maciek Majewski, tym razem nietypowo, bo... o aplikacjach sieciowych. Konkretniej o wiosennych pływach, a wiadomo, że wiosną wszystko pływa żwawiej.

Potem losowanie nagród, chwilka sprzątania, i można było wpaść na integrację (pozdrawiamy Lublin, Warszawę, Wrocław i kogo tam jeszcze przywiało), napić, najeść się, lulków napalić, karczmy ledwo nie rozwalić... Oby za rok, było co najmniej równie fajnie (czyli, Leszku, wreszcie coś wygram, zgoda? ;)).

P.S. Jak widać po pierwszych komentarzach temu Panu i temu też się podobało, więc chyba coś być na rzeczy musi... ;)

czwartek, 2 kwietnia 2009

NSIS - obsługa różnych typów plików konfiguracyjnych

Sława!

Czasami zdarza się, że robiąc instalator do swojej aplikacji, chcemy jednocześnie zawrzeć w nim podstawową konfigurację swojego produktu tak, aby po procesie instalacji nadawał się on w większości przypadków już do użycia. Jeżeli dla tego produktu konfiguracja taka sprowadza się do wypełnienia dwóch, trzech pól i zapisania ich wartości w docelowym pliku, nie nastręcza to zbytnich trudności. Ot, wystarczy zrobić plik *.ini strony, skrobnąć funkcję obsługi i voila. Pikuś, morda, gitara gra. :)

Problemik (ale przecież, jak zawsze w naszym wypadku, tyci, tyciunki ;)) może się zacząć robić wtedy, kiedy tych produktów zaczyna być więcej, albo tych pól do konfiguracji zaczyna się mnożyć ponad jedną stronę, albo...

Wtedy przydałoby się oczywiście jakoś sobie pracę usprawnić. Jednym z możliwych rozwiązań, jest wykorzystanie do tego celu plików... *.ini. Otóż okazuje się, że każdy z elementów strony, jak i strona jako całość może mieć również właściwości niestandardowe, które można wykorzystać do przechowywania informacji potrzebnych dla naszych uniwersalnych funkcji/makr obsługujących konfigurację.

Załóżmy, że plik konfiguracyjny jest plikiem XML, wtedy do pól dodawać możemy informację o XPath skąd i gdzie potrzebujemy pobrać i zapisać wartości. W naszym pliku ini znaleźć się może więc coś takiego.

[Settings]
NumFields=3
TargetFile=config.xml

[Field 3]
Type=GroupBox
Left=3
Top=4
Right=145
Bottom=135
Text=Configuration

[Field 1]
Type=Label
Left=9
Top=15
Right=110
Bottom=24
Text=SMTP server:

[Field 2]
Type=Text
Left=9
Top=26
Right=141
Bottom=36
State=smtp.host
MinLen=1
Flags=
XPath=/mail-module/mail-sender/smtp-host

Natomiast kod odpowiedzialny za inicjalizowanie wyświetlania strony miałby postać mniej więcej taką:

${xml::LoadFile} '$TARGETDIR\$TARGETFILE' $0
${If} $0 == 0
   ReadIniStr $NUMFIELDS $INIFILE "Settings" "NumFields"

   ${For} $R9 1 $NUMFIELDS
      ${xml::RootElement} $0 $1
      ReadIniStr $XP  $INIFILE 'Field $R9' 'XPath'

      ${If} $XP != ""
         ${xml::XPathNode} $XP $0

         ${If} $0 == 0
            ${xml::GetText} $1 $0
         ${EndIf}

         ${If} $0 == 0
            WriteINIStr $INIFILE 'Field $R9' 'State' '$1'
         ${Else}
            MessageBox MB_OK|MB_ICONEXCLAMATION 'Error during reading:$\r$\nFile: $TARGETDIR\$TARGETFILE$\r$\nXpath: $XP'
         ${EndIf}
      ${EndIf}
   ${Next}

   InstallOptions::initDialog /NOUNLOAD $INIFILE
   Pop $HWND

   InstallOptions::show /NOUNLOAD
${Else}
   MessageBox MB_OK "Can't find file: $TARGETDIR\$TARGETFILE"
   Abort
${EndIf}

Na analogicznej zasadzie konstruujemy funkcje zapisujące do pliku XML, używając mniej więcej czegoś takiego:

ReadIniStr $NUMFIELDS $INIFILE "Settings" "NumFields"

${For} $R9 1 $NUMFIELDS
   ReadIniStr $XP  $INIFILE 'Field $R9' 'XPath'

   ${If} $XP != ''
      ReadIniStr $0 $INIFILE "Field $R9" "State"
                  
      ${xml::RootElement} $1 $1
      ${xml::XPathNode} $XP $1
      ${xml::SetText} $0 $1
      ${xml::SaveFile} '$TARGETDIR\$TARGETFILE' $1
   ${EndIf}
${Next}

Dzięki temu tworzenie kolejnych konfiguracji sprowadzi się jedynie do ustawienie odpowiednich wartości w plikach *.ini. Jeżeli jeszcze wydzielimy sobie wieloużywalny kod do plików nagłówkowych, tworzenie instalatorów na pęczki będzie niczym bułka z masłem na śniadanko. :)