Plesk instalacja w linuksie

Trochę się naszukałem aby zainstalować pleska 8.4 na CentOsie. Jednak oficjalna dokumentacja spełnia swoją rolę. Ten sposób instalacji jest uniwersalny i niezależny od dystrybucji.

Na początku pobieramy autoinstaller dla naszego systemu i odpowiednią wersję stąd. Wymagana jest rejestracja.
Po pobraniu pliku przechodzimy do katalogu gdzie on jest zapisany i nadajemy mu prawa do wykonywania

chmod +x pobrany_instalator_plesk

i uruchamiamy za pomocą komendy:

./pobrany_instalator_plesk

i generalnie wystarczy naciskać cały czas enter. Chyba, że jest potrzeba zmiany ścieżek, parametrów czy dodatkowych komponentów to wtedy wybieramy odpowiednią literę lub cyfrę i enter.
Po tych czynnościach pod adresem http://ipMaszyny:8443 jest dostępny panel plesk. Można się zalogować przez login admin a domyślne hasło to setup.

Niestety to rozwiązanie ma pewną wadę a mianowicie zależy od konkretnych wersji pakietów. Jeśli w systemie mamy nowszą wersję np. postgresa niż wymagana to instalacja nie powiedzie się. Komunikat o konflikcie pakietów zostanie wyświetlony na konsoli.

Porządki w faces-config

Pierwszy raz jak zobaczyłem w jaki sposób jest zorganizowana nawigacja w jsf bardzo mi się to spodobało. Moja radość z tego powodu trwała do momentu gdy pojawiło się trochę więcej stron, które korzystały w większości z tych samych reguł nawigacyjnych. Rozwiązując test na javablackbelt pojawiło mi się pytanie związane z tym problemem. Nie znałem odpowiedzi ale zaznaczyłem taką odpowiedź, którą bym chciał aby była prawdziwa. I tak się stało.


<navigation-rule>
  <from-view-id>*</from-view-id>>
  <navigation-case>
    <from-outcome>something</from-outcome>>
    <to-view-id>/page.jsp</to-view-id>>
  </navigation-case>
</navigation-rule>


Poprsostu genialne rozwiązanie. Gwiazdka zastępuje nam dowolną stronę czyli mamy globalną nawigację dla wszystkich stron, a pozostało tylko obsłużenie specyficznych zachowań strony.

A może ktoś zna sposób jak jeszscze można zrefaktoryzowac faces-config?

Załączanie stron w jsf

Chyba każdy z programistów zna zasadę, a conajmniej o niej słyszał, DRY (Don’t Repeat Yourself). Bardzo ogólnie polega ona na unikaniu powtórzeń kodu. W dobrze zaprojektowanych i utrzymywanych aplikacjach javowych nie jest trudno jej przestrzegać. Im program staje się bardziej skomplikowany, więcej osób go pisze tym bardziej przestrzeganie tej zasady staje się trudniejsze, ale to nie o tym jest ta bajka.

Trochę trudniejsza sprawa jest z tworzeniem stron jsp (a właściwie jsf, o czym będe pisał). O ile jeszcze jakieś statyczne elementy jak stopka czy nagłówek moża łatwo wyodrębnić, to może pojawić się problem z listami, tabelkami, formatkami, które są w wielu miejsach takie same bądź rożnią się nieznacznie od siebie. Chyba najlepszym rozwiązaniem jest includowanie części podstron do docelowej strony.

JSF w standardzie udostępnia nam kontrolkę . Próbowałem z niej korzystać i wszystko było dobrze do momentu aż CSS został dodany do strony. Załączana strona nie widziała arkuszu stylów. Kilka sposobów, które znalazłem niestety nie zapewniły mi powodzenia. Rozwiązaniem na którym się wzorowałem można znaleźć tutaj.
Tworzymy cześć naszej strony w odzielnym pliku i zapisujemy jako jsp. Taki plik może mieć w sobie załączone kolejne fragmenty stron. A następnie dołączamy taką stronę poprzez

<h:panelGroup>
 <jsp:include page="includedPage.jsp" />
</h:panelGroup>


To rozwiązanie sprawiło, że CSS był widoczny dla komponentów na dołączonej stronie oraz dodatkowo w kodzie było mniej śmieci niż subview generuje.
Ważna sprawą jest dołaczenie dyrektyw jsf do podstron(jeśli korzystają one z backing beanów), bo w przeciwnym razie można dostać wyjątek o niemożliwości sparsowania strony. Oraz uważać aby id komponentów się nie powtarzały.

Wymagany checkbox w jsf (required checkbox in jsf)

Kontrolki w jsf posiadają bardzo ciekawy atrybut a mianowicie “required”. Ustawienie jego na true zapewnia, że submit nie zostanie zatwierdzony dopóki, wymagane pole nie będzie uzupełnione. I samemu nie trzeba tego oprogramowywać.

Jednak dla wymaganych checkboxów pojawia się problem. Atrybut required sprawdza czy dany komponent nie jest nullem a nie zaznaczony checkbox ma wartość false. Która równocześnie jest wartością domyślną dla komponentów. Ale i z tym problemem można się uporać, pisząc własny walidator dla checkboxów w backing beanie.

Na stronie jsp dla checkboxa dodajemy wskazanie na metodę walidującą w beanie i ustawiamy atrybut required na true.
<h:selectBooleanCheckbox id="accept"
   validator="#{RegistryBean.validateCheckbox}"
   value="#{RegistryBean.accept}" required="true">
</h:selectBooleanCheckbox>

Natomiast metoda sprawdzająca czy checkbox jest wymagany wygląda następująco:
public void validateCheckbox(FacesContext context, UIComponent component, Object value) {
  if (value instanceof Boolean && ((Boolean) value).equals(Boolean.FALSE)) {
    FacesMessage message = new FacesMessage("You must choose checkbox");
    throw new ValidatorException(message);
  }
}
I tutaj walidator sprawdza czy nasz checkbox jest nie zaznaczony. Jeśli użytkownik nie zaznaczył checkboxa zostaje rzucony wyjątek ValidatorException, który pokazuje użytkownikowi, że dane pole jest wymagane za pomocą przyjaznego komunikatu.