čtvrtek 27. prosince 2007

Anotace nahrazující SQL a OQL dotazy (popis)

Bez dalších řečí se rovnou pustím do popisu.
Jak už jsem předeslal, základem dané filtrace nad daty, jsou anotace. Uvedu jejich výčet a popis.

@Criteria (class)
Jedná se o základní anotaci, která říká, že se jedná o "filtrační" objekt, který je schopen nabídnout své atributy k porovnání. Jediným parametrem je entita, která říká o jakou entitu se jedná.

@Criterion (atribut)
Popisuje atribut, který je automaticky brán jako jeden z prvků filtrace. Samotná anotace obsahuje moznosti, které označí, jak se k danému atributu bude přistupovat.
Zde je výčet některých z nich:

  • property - název atributu podle dané entity, může se jednat i o vnořenou hodnotu (zakaznik.id)

  • operator - definuje typ porovnávání mezi hodnotou atributu a názvem atributu, typ porovnávání je výčtový typ, který lze rozšířit

  • excludeEmptyString - určuje, zda se bude brát v potaz prázdný String či se bude ignorovat


V budoucnu předpokládám rozšíření těchto vlastností. Ale držím se pravidla: Méně je někdy více. Přeci jen nechci tvořit kód, který bude obsahovat spoustu deprekovaných způsobů.

@Between (atribut)
Složení minimální a maximální hodnoty, která je prováděna na základě definovaného idf a property, což je výčtový typ, který může být buď MIN či MAX. Výhodou tohoto použití je také v tom, že pokud jedna z hodnot neexistuje, automaticky převádí BETWEEN na porovnání jedné hodnoty. Pokud například hodnota pro MAX bude empty a MIN bude existovat, bude generována následující podmínka: WHERE datum >= 'hodnota'.

@Conjunction (atribut)
Konjunkce funguje podobně jako v Criteria API. Na základě definovaného idf se spojí ty hodnoty, které k sobě patří. Zde ovšem existuje jedno omezení (stejně jako u disjunkce): Vnořené podmínky. Je to další krok, který budu muset vyřešit.

@Disjunction (atribut)
Opět podobný způsob jako v případě konjunkce. Zde se tedy generuje něco jako: WHERE (property [operator] value OR ....). Spojení daných atributu se opět provádí pomocí stejného názvu v idf.

@Alias (class)
Jelikož se často stává, že se potřebuji dotazovat na sloupec, který je v nějaké tabulce, která je v relaci s danou entitou, potřebuji aliasovat danou entitu, pro kterou bude platit nasledující alias.
Zde rovnou uvedu příklad:
Mám zaměstnance, který spadá do daného střediska, z kterého chci znát název, podle kterého filtruji. V OQL by mohl dotaz vypadat následovně: FROM Zamestnanec z WHERE z.stredisko.nazev = 'Vyroba'. V Criteria API se k danému sloupci dostanu přes alias, takže by to mohlo vypadat následovně: @Alias(associationPath = "stredisko", alias = "s").
Aby bylo možné definovat aliasů více, existuje anotace s nazvem Aliases, která může obsahovat pole daných aliasů.

@OrderBy (class)
Poslední popisovaná anotace slouží k definování řazení dat. Jelikož požadavek na řazení dat je častým jevem, existuje možnost nadefinovat filtračnímu objektu tuto vlastnost. Daná anotace obsahuje pole anotací s názvem @OrderValue, která má dvě vlastností a tím je název atributu pro řazení a typ řazení, který je výčtvový typ ASC nebo DESC.

Samotné použití je postaveno na DetachedCriteria. Ti, co znají Hibernate vědí, že se jedná o criteria, které neobsahují Session. Jinými slovy, takováto criteria si můžete vytvořit ještě v době, kdy o Hibernate Session nemá Váš kod ani ponětí. Jistě je to dobrý způsob jak zajistit určité odělení od zbytku vlastní implementace.

K přístupu slouží třída s názvem: "CriteriaDAOFactory". Jak už název napovídá, jedná se o factory, která vrací interface CriteriaDAO. Daný interface již obsahuje metodu vracející DetachedCriteria.
Dané použití může vypadat následovně:
MyFiltr filtr = new MyFiltr();
// naplneni filtru
CriteriaDAO d = CriteriaDAOFactory.getCriteria(filtr);
DetachedCriteria dc = d.getDetachedCriteria();


Nyní uvedu několik příkladů definování daného filtru a jeho ekvivalent v podobě SQL dotazu. U všech ukázek vynechám settry a gettry, které jsou nezbytnou součástí. Pokud někdo chce tvořit neměnný objekt, tak samozřejme settry může vynechat. Takže jedem:

@Criteria(entity = Zamestnanec.class)
public class ZamestnanecFiltr {

@Criterion(property="cislo")
private String id;

@Criterion(operator=RestrictionDAO.LIKE)
private String prijmeni;
}

SELECT * FROM zamestnanec
WHERE cislo = 'value' AND prijmeni LIKE '%value%'


@Criteria(entity = Zamestnanec.class)
@OrderBy(values={@OrderValue(name = "prijmeni")})
@Alias(associationPath = "stredisko", alias = "s")
public class ZamestnanecFiltr {

@Criterion(property="s.nazev")
private String nazev;

@Criterion(property="datumPrijeti")
@Between(idf = "dp", property = BetweenDAO.MIN)
private Date datumOd;

@Criterion(property="datumPrijeti")
@Between(idf = "dp", property = BetweenDAO.MAX)
private Date datumDo;
}

SELECT * FROM zamestnanec z
INNER JOIN stredisko s ON z.stredisko = s.cislo
WHERE s.nazev = 'value' AND z.datumPrijeti BETWEEN 'min' AND 'max'
ORDER BY z.prijmeni


Tím bych asi ukončil tento popis. Samozřejmě, lze dané věci dobře kombinovat. Je jasné, že se naleznou další potřebné funkce, které nechám spíše vyplynout postupem času. Pokud by někdo měl zájem, mohu se pokusit danou funčnost implementovat.

Poslední věcí, kterou chci zmínit je pár otázek, které bych rád nějak vyřešil. Jelikož vše má svá úskalí... Pokud bude mít někdo zájem, budu vítat jakoukoli pomoc či nakopnutí.

  • řazení dat je definováno staticky, jak implementovat dynamický způsob

  • specifikování získaných dat, jak omezení na určité sloupce, tak vlastní DTO či inicializace LAZY

  • vnořené konjunkce a disjunkce, které závisí na předchozích podmínkách, a zda má vůbec cenu něco takového implementovat

  • dynamické rozhodování zvoleného operátoru, uživatel například může mít k dispozici volbu mezi (LIKE, <, >, =)



Samotný projekt je psán v NetBeans, proto ho také jako NetBeans projekt vystavuji. Předem se omlouvám za absenci JUnit testů. Upřímně, zatím jsem neměl dostatek času vše otestovat a navíc testy mám komponovány přímo na danou specifikaci, ke které je třeba existence daného modelu a zdroje. Samotná implementace je závislá na Hibernate API a na log4j. Knihovna log4j je v adresáři lib, knihovny pro Hibernate neuvádím záměrně. Pro práci s Hibernate existuje mnohem větší závislost :)

Projekt ke stažení: IrminsulCriteria

IrminsulCriteria

Anotace nahrazující SQL a OQL dotazy (důvody)

V minulém příspěvku jsem psal o tom, jakým způsobem nadefinovat základní DAO vrstvu. Zvolil jsem způsob, který se stal zavislý na Hibernate Session. Tento "vendor" nabízí i jednu z věcí, kterou jsem si pomalu oblíbil, a tím jsou Criteria API.

Psaní základních SQL dotazů jsem nahrazil OQL dotazy. OQL je v podstatě velice podobný SQL s tím rozdílem, že daný dotaz se provádí nad entitami reprezentující data v DB. Díky tomu odpadá nutnost psát ruzné JOIN konstrukce, specifikovat vrácené sloupce a hlavně získávám nezávislost na použitém databázovém systému. Převod z MySQL na Oracle či MSSQL je triviální záležitost spočívající v přepsání pár řádku v persistence.xml či v přepsání JDBC zdroje v aplikačním serveru.

Ale zpět. I když je OQL velice elegantní způsob psaní, stále obsahuje velké omezení, které spočívá v tvorbě dynamických dotazů. Pokud aplikace přistupuje k datům tak, že je získává na základě uživatelského filtru, musím dotaz poskládat z daného Stringu, což je dost otravující záležitost.
K tomuto účelu se velice hodí Criteria API. Nebudu zde popisovat funkci Criteria API, k tomuto účelu slouží referenční příručka. U Criteria API se mi velice zalíbila možnost filtrovat data přes danou entitu. K tomuto účelu zde existuje objekt "Example". Při použití tohoto přístupu mohu velice snadno získat data filtrovaná podle daných sloupců (atributů) v tabulce (entitě).

Jenže....

Pokud si například řeknu: "Chci vybrat všechny záznamy s podmínkou WHERE datum BETWEEN od AND do", dostanu se opět do slepé uličky a musím přistoupit zpět k čistému Criteria API nebo dokonce k OQL.

Toto byl první důvod, proč jsem přistoupil k implementaci vlastního způsobu, který je řízen pomocí anotací. Ještě než přejdu k samotnému způsobu, musím zmínit druhou pozitivní věc.

Pokud začnu tvořit DAO vrstvu, začne se mi každý DAO objekt hemžit metodami jako: findByDatumPrijeti, findByXXX.... Jistě není nic špatného na implementaci daných metod, až na to, že metody obsahují parametry, které již jasně říkají, jaká data mají být výsledkem (návratovou hodnotou).
Uvedu malý příklad (pro pozdější srovnání):

public List findForExample(String zakaznik, Date datumOd, Date datumDo) {

// implementace Criteria API, OQL ci suroveho SQL

}


Jak je z ukázky patrné, metoda vybíra zakázky, které spadají jistému zákazníkovi a jejich datum je v rozmezi datumOd-datumDo.

K odstranění psaní samotných dotazů použiji následující kroky:

  • vytvořím objekt pro filtraci

  • daný objekt anotuji příslušnými "metadaty"

  • zruším metodu findForExample a v DAO vytvořím obecnou metodu: findByCriteria(Object filtr)



Jediné, co mi zůstane je objekt pro filtrování. Sám se svými metadaty je schopen řici, co vlastně chci. Následující ukázka je ekvivalentní předchozímu způsobu:

@Criteria(entity = Zakazky.class)
public class ZakazkyForExampleFiltr {

@Criterion(property="zakaznik.id")
private String zakaznik;

@Criterion(property = "datumPrijeti")
@Between(idf = "dp", property = BetweenDAO.MIN)
private Date datumPrijetiOd;


@Criterion(property = "datumPrijeti")
@Between(idf = "dp", property = BetweenDAO.MAX)
private Date datumPrijetiDo;

// settry, gettry
}

// pouziti
ZakazkyForExampleFiltr filtr = new ZakazkyForExampleFiltr();
// naplneni filtru
List result = dao.findByCriteria(filtr);


Pro lidi nesnášející anotace, bude tento způsob jistě nepoužitelný, pro lidi snažící se o co největší usnadnění a zpřehlednění své práce, naopak přínosem. Věřím, že každý si již ten svůj zpusob nalezl a nehodlá ho měnit, na druhou stranu při pohledu na takovýto kod si pokládám jednu otázku: "Není přece jen efektivnější popsat kod metadaty a nechat zbytek na daném frameworku?".

Jelikož se mi článek rozrostl, rozhodl jsem se ho rozdělit do dvou částí. V první části jsem popsal důvody a uvedl malou ukázku. V druhé části uvedu možnosti a nabídnu danou funkčnost ke stažení. Tedy ten základní "motor", který lze jednoduše "přilepit" do své DAO vrstvy. Navíc uvedu další plány a položím otázky, na které si zatím nedokážu odpovědět.

čtvrtek 13. prosince 2007

DAO pattern + generika pro EJB3

Když jsem se dostal do fáze většího poznávání J2EE, došlo mi, že vrstvení logiky je nedílnou součástí úspěchu při návrhu.
Jistě by nebylo moudré nechat "dolování dat" rozházené po aplikační logice tak, jak ho zrovna potřebuji. Zde nastupuje DAO (Data Access Object), což je návrhový vzor sloužící ke komunikaci mezi persistentní vrstvou a zbytkem světa.

Asi nejvíce mě zaujala možnost, kde DAO vrstvu definuji pomocí generiky a abstraktní třídy. Více než tisíc slov je lepší přímá ukázka kódu.

První věcí je interface, který obsahuje všechny důležité metody, které je třeba pro DAO jednotlivých entit třeba vystavit:
public interface GenericDAO {
public T find(ID id);
public List findAll();
public T create(T entity);
public T save(T entity);
public void remove(T entity);
}

Jednotlivé metody jsou vcelku jasné. Jedná se o základní operace jako: získej data, vytvoř, ulož, smaž. Co se týče generických typů, jedná se o entitu, které přísluší dané DAO a o typ primárního klíče. Typem primárního klíče může být jak základní datový typ jako String, Integer, tak i složený primární klíč, např: ZakazkaPK (obsahuje číslo zakázky a datum vystavení).

Nyní mohu přejít k vlastní implementaci lokálního interface:
@Local
public interface ZamestnanecDAOLocal extends GenericDAO {
}

Samotná EJB beana může vypadat následovně:
@Stateless
public class ZamestnanecDAOBean implements ZamestnanecDAOLocal {
@PersistenceContext(unitName = "myDB")
private EntityManager em;
//... implementace metod
}


Velkou nevýhodou je ovšem fakt, že pokaždé musím implementovat metody, které jsou potřeba ke splnění požadavku z GenericDAO.

Zde nastupuje abstraktní třída, která za nás vyřeší onu potřebnou implementaci.
public abstract class AbstractDAO implements GenericDAO {
private Class entityBeanType;
private EntityManager em;
public AbstractDAO() {
// vytvari, ziskava typ entity pro dane DAO
this.entityBeanType = (Class) ((ParameterizedType)
getClass().getGenericSuperclass())
.getActualTypeArguments()[0];
}

public Class getEntityBeanType() {
return entityBeanType;
}

@PersistenceContext(unitName = "default")
public void setEntityManager(EntityManager em) {
this.em = em;
}

protected EntityManager getEntityManager() {
if (em == null) {
throw new IllegalStateException("...");
}
return em;
}

public T find(ID id) {
T entity;
entity = getEntityManager().find(getEntityBeanType(), id);
return entity;
}

// ... implementace zbylych metod
}


Nyní stačí danou abstraktní třídu nechat dědit samotnou implementací EJB beany:
@Stateless
public class ZamestnanecDAOBean extends AbstractDAO implements ZamestnanecDAOLocal {
}


Takto definovaná beana je schopna podědit abstraktní třídu a například anotovaný setter pro entitymanager převzít na svá bedra. Podle specifikace je totiž možné EJB beany nechat dědit mezi sebou, s vyjímkou, že dependency injections a další služby jsou poté managovány potomkem, v našem případě "ZamestnanecDAOBean".

Aby samotné DAO nebylo tak chudé, přidal jsem si několik dalších možností. Některé jsou již specifikovány na danou implementace ORM frameworku. Osobně jsem díky tomu přešel na Hibernate Session a Criteria API.
Tady jsou některé další metody:

/**
*

Vraci vsechny zaznamy z dane tabulky, ktera prislusi entite.
* Navic umoznuje definovat razeni podle Hibernate Criteria API: Order


*

Zpusob pouziti: {@code findAll(Order.asc("jmeno"), Order.desc("prijmeni"))}


*
* @param orderBy definice razeni zaznamu
* @return vsechny zaznamy, pokud zadne neexistuji, vraci null
*/
public List findAll(Order... orderBy);

/**
*

Vraci vsechny zaznamy z dane tabulky, ktera prislusi entite.
* Navic umoznuje definovat omezeny vyber dat, pouzivane napr. pro strankovani.


*

Zpusob pouziti: {@code findAll(0, 20); } Prvni radek je roven 0


*
* @param first prvni radek, od ktereho se vybiraji zaznamy
* @param offset maximalni pocet vybiranych zaznamu
* @return vsechny zaznamy dle definovanych omezenich
*/
public List findAll(int first, int offset);

/**
*

Vraci vsechny zaznamy z dane tabulky, ktera prislusi entite.
* Navic umoznuje definovat omezeny vyber dat, pouzivane napr. pro strankovani
* a definovat razeni podle Hibernate Criteria API: Order


*

Zpusob pouziti: {@code findAll(0, 20, Order.asc("jmeno")); } Prvni radek je roven 0


*
* @param first prvni radek, od ktereho se vybiraji zaznamy
* @param offset maximalni pocet vybiranych zaznamu
* @param orderBy definice razeni zaznamu
*
* @return vsechny zaznamy dle definovanych omezenich
*/
public List findAll(int first, int offset, Order... orderBy);

/**
*

Dohledava zaznamy na zaklade Hibernate Example.


*

Spousti: {@code findByExample(exampleInstance, false, false, false, excludeProperty)}


*

Zpusob pouziti: 15.6. Example queries
*
* @param exampleInstance s naplnenymi vlastnostmi pro vyber
* @param excludeProperty pradavajici vlastnosti pro vyber pres example
* @return dohledane zaznamy
*/
public List findByExample(T exampleInstance, String... excludeProperty);

/**
*

Ziskava pocet vsech radku z tabulky prislusici dane entite


*
* @return pocet vsech radku
*/
public int countAll();

pondělí 3. prosince 2007

Seam & Hibernate Validator

Když jsem přemýšlel nad tím jak validovat (kontrolovat) data od uzivatele, napadlo mě spoustu možností jak to řešit. Jeden je ovšem velice sexy, který stojí za to zmínit.

Mám klasickou webovou aplikaci postavenou pomocí MVC (model-view-controller). Do modelu můžu nacpat entity, do kontroleru jednotlivé akce nad modelem a komunikace mezi view a business logikou. Do view klasické webové stránky.
Jelikož je Java striktně typový jazyk, nutí mě již na základě modelu definovat typ tak, aby odpovídal skutečnosti. Při vystavení modelu do persistentní vrstvy, ode mně navíc očekává popis jednotlivých atributů, podle kterého komunikuje s databází.

Ale zpět k view.
Začnu tvořit klasický formulář, který například obsahuje vlastnosti uživatele. Musím ošetřit, že login nesmí být prázdný, že musí splňovat podmínku, která říká, že použitelné znaky jsou pouze daného výčtu. Podobné vlastnosti budu kontrolovat například u hesla či jména a příjmení. Dané kritéria, které musí uživatel, při vyplňování formuláře, splnit, jsou identická s kritériemi, které musí splnit model (entita), aby byla schopna se persistovat (uložit) do databáze.
Abych se vyhnul duplicitní validaci, existuje možnost tyto věci propojit. Zde právě nastupuje Seam framework a Hibernate Validator. Nejlépe bude, pokud vše vysvětlím na malé ukázce:

Mám entitu uživatele, která může vypadat následovně:
@Entity
@Name("uzivatel")
public class Uzivatel implements Serializable {
@Id
@NotNull
@Length(min=5, max=30)
@Pattern("^\w*$", message="#{message.errorValidateLogin}")
private String login;
@NotNull
@Length(min=6)
private String heslo;
private String jmeno;
private String prijmeni;
// ... settry, gettry
}


Danými anotacemi jsem dal najevo, že model musí splnit tyto požadavky. Pokud se tak nestane, nepodaří se mi mi danou hodnotu uložit do databáze.

Tak a teď k view.
Mám v podstatě 2 možnosti, buď budu znovu psát pravidla pro validaci, nebo nechám vše na frameworku.







Při pokusu odeslání formuláře, dostanu hlášení, že jsem nesplnil daná kritéria. K tomu ale dojde ještě dříve, než se model dostane k persistentní vrstvě. To znamená, že validace se provádí hned při spuštění akce "registrace".
Jednotlivé hlášky, které posílá Hibernate Validator jsou přeložitelné, takže není problém si udělat vlastní definici, která mi jasně řekne: "Nene, máš chybu, chyby jsou... zde a zde...".

Je to jedna z vlastností Seamu, která mě pomalu nutí více používat Hibernate :)

Příjemných vlastností v Seam frameworku mohu nalézt více. Ve zkratce uvedu, pro mne, ty nejzásadnější:

  • Hot deploy - mohu provádět změny nad aplikací, bez nutnosti restartovat server či provádět redeploy aplikace

  • @In, @Out - Jednotlivé komponenty mohu zasazovat do logiky či je dále vystavovat; v ukázce je vidět, že uživatele jako komponentu přímo použiji v xhtml stránce, aniž bych musel používat nějaký controller nad modelem

  • @Scope - výčet životností komponent je mnohem bohatší, než je tomu v JSF

  • @Logger - přímá podpora logování pomocí log4j

  • pages.xml - pageflow, které umožňuje mnohem větší možnosti než je tomu u navigation-rules v JSF

  • No POST - díky Seamu, který umožňuje používat konverzaci, nemusí být view posílán přes POST

  • security - Seam obsahuje docela pěknou práci s rolemi, uživateli a vůbec s restrikcemi; navíc umožňuje ručně definovat práva a jejich chování


  • components.xml, exceptions.xml - konfigurovat se dá snad vše, ať už jsou to komponenty či zachytávání výjimek



Výčet by byl jistě mnohem bohatší. I když s daným frameworkem nemám tolik zkušenností, ihned jsem si ho oblíbil. Důvodem je možná i samotná referenční příručka, která mi odpoví téměř na všechny dotazy.

čtvrtek 29. listopadu 2007

Novinky 2

Jsem tu s další sadou novinek či událostí, které mě v poslední době asi nejvíce zaujaly. Bez dalších řečí, rovnou začnu:

NetBeans:
Jelikož jsem velkým fandou tohoto IDE a i samotné RCP platformy, jsem rád, že se blíží konečné vydání. Nyní je k dispozici NetBeans RC2, která navíc byla uživateli označena za použitelnou a připravenou k releasnutí.

Facelets:
Byl to pro mě trn v oku. Sice již několik měsíců používám NB6, ale bohužel bez podpory, která mi dost usnadňuje život. Nicméně, podpora facelets je na světě! Sice se jedná o testovací verzi, ale i tak jsou již některé věci použitelné.

Seam 2.0:
Jak již psal Petr Ferschmann, Seam 2.0 se konečně dostal do fáze GA. Po přechodu na tuto verzi jsem si zejména liboval v konfiguraci. Pokud projdete referenční příručku (mimochodem takhle si představuji studijní materiál, výborně napsaná), zjistíte, že nyní již není třeba konfigurovat tolik vlastností. Tímto ovšem apeluji na Petra Pišla (všemohoucí díky za podporu facelets), aby oprášil NetBeans plugin pro Seam 2.0. :)

MySQL:
V poslední době mi přijde, že nějak strnul vývoj tohoto produktu. Nyní je k dispozici MySQL 5.0.x, která jako jediná je GA. Zbytek je stále v aplha či RC verzi. Osobně jsem dost zvědavý na Falcon engine, který by měl nastoupit na místo InnoDB a míti rychlost srovnatelnou s MyISAM. Jenže, kde nic tu nic.
Ale proč přidávám toto do novinek? Před nedávnem mě dost vypekl konektor pro Javu. Při použití MySQL Connector/J 5.1.5 společně s Hibernate 3.2.x jsem se dostal do stavu, kdy hibernate nebyl schopen vytvářet "auto_increment", který má nastarosti právě MySQL. Při přechodu zpět na MySQL Connector/J 5.0.x je vše v pořádku. Možná se MySQL rozhodlo MySQL Connector/J verzovat stejně jako své verze Database Serveru.

Video Netbeans RCP vs. Eclipse RCP:
Konečně vyšlo toužebně očekávané video, kterého jsem se osobně zůčastnil. Každému vřele doporučuji. I když zrovna člověk neplánuje využít dané platformy, pro všeobecný přehled nad modulárními systémy, by si měl video prohlédnout.
Malý tip: No a když se dostanete na konec videa, tak mě můžete zahlédnout. Jsem ten poslední a jediný tazající :)

Exceptions for Action:
Poslední novinkou je článek na javaworld.com s názvem Exceptions for Action. Jedná se o hezký popis, jak správně navhovat výjimky uvnitř J2EE. Abych byl upřímný. I když rozumím způsobu práce výjimek, je pro mě velká magie je správně navrhovat a pracovat s nimi.

Tak to by bylo vše. Ještě jedna malá věc pro pobavení: Přáníčka od kofoly.

pátek 23. listopadu 2007

JBoss Seam 2.0 & Hibernate 3.2.5 & Glassfish V2

Když jsem přemýšlel jaký zvolím framework pro webovou aplikaci, naskytly se mi v podstatě dvě možnosti. Buď JSF či Struts. Osobně jsem raději hned sáhnul po JSF. Komponentový framework, navíc tolik dotovaný samotným Sunem.

Po vyzkoušení pár příkladů jsem ihned přešel do vývoje. Zde ovšem nastaly potíže. Psaní stejného kódu stále dokola. Stálá definice přes XML, neexistence použitelného scope pro komponenty. Navíc jsem na vývoj sám a přijde mi příliš těžkopádné vše striktně oddělovat.

Našel jsem Seam. Jedná se o webový framework od JBosse, který tvoří ono lepidlo mezi JSF a EJB3. Samotná definice komponent je plně řízena anotacemi, čímž odpadají mnohé XML definice. Seam navíc obsahuje dosah komponenty „conversation“. Taková komponenta poté existuje od doby vzniku konverzace až do jejího zániku. Odpadá tak potřeba definovat komponenty jako „session“. Další věcí, která mě zaujala byla podpora Hibernate Validatoru. Pokud použiji Hibernate, mám možnost nechat Seam, ať mi jednotlivé hodnoty entit validuje podle definice z Hibernate.

Já se zde nechci zabývat podrobnostmi, jak daný Seam funguje, k tomu slouži referenční příručka. Mimochodem skutečně výtečně napsaná. Spíše se zaměřím na to, jak nainstalovat Seam 2.0 na Glassfish V2.

Seam je primárně určen pro aplikační server Jboss. Pravdou ovšem je, že ho lze použít i na jiném serveru či přímo bez EJB kontejneru (viz. Tomcat). Samotná konfigurace se liší jen nepatrných věcech. Mě ovšem dali pekelně zabrat :)

Takže, nejprve je nutné stáhnout samotný Seam 2.0 a Hibernate. Již přímo v examplech existuje ukázková aplikace s názvem booking (v adresáři jee5). Jedná se o web. aplikaci pro hotel, kde si můžete zamluvit vlastní aparmá. Na aplikaci je vysvětlené jak funguje komunikace mezi Seamem, JSF a JPA.

Při tvorbě vlastní aplikace si musím nejprve zaregistovat dané knihovny.
Pro webovou vstvu to je:

  • el-api.jar

  • el-ri.jar

  • jsf-facelets.jar

  • jboss-seam-ui.jar


Pro EJB modul:

  • jboss-seam.jar

  • jboss-seam-debug.jar

  • hibernate-all.jar

  • thirdparty-all.jar



EJB Modul dále musí obsahovat conf/seam.properties, který může být klidně prázdný. Definice persistence.xml, kde je třeba, aby byla správně nastavena transakce:




org.hibernate.ejb.HibernatePersistence
my/db



value="org.hibernate.cache.HashtableCacheProvider"/>








Webový modul:
Jednak obsahuje web.xml, kde je třeba dodefinovat Seam:



org.jboss.seam.servlet.SeamListener



Seam Filter
org.jboss.seam.servlet.SeamFilter



Seam Filter
/*



Seam Resource Servlet
org.jboss.seam.servlet.SeamResourceServlet



Seam Resource Servlet
/seam/resource/*




A jednak reference na EJB Beany.

For Transaction from EJB3 Container
Irminsul/EjbSynchronizations/local
Session
org.jboss.seam.transaction.LocalEjbSynchronizations
EjbSynchronizations



MyEARName/MyBean/local
Session
ejb.seam.app.MyLocal
MyBean


Je to trochu nevýhoda oproti použití samotného Jbosse, kde reference jsou dohledany automaticky.

Dalšími konfiguračními soubory jsou:

  • components.xml

  • exceptions.xml

  • pages.xml

  • security.drl



V components.xml se definují jednotlivé vlastnosti Seamu jako jndi-pattern, security, atd.






concurrent-request-timeout="10000"
conversation-id-parameter="cid"/>















/WEB-INF/security.drl



Zaregistrování JNDI patternu je potřebné pro referencování EJB Bean. Dále nastavím, že transakce je řízena přes EJB kontejner, kde si Seam dokáže odchytit i exeptions při rollbacku.
Dále se jedná o nastavení časové platnosti konverzace.
Poslední věcí je authentifikace a nadefinovaní pravidel pro práci s rolemi a celkovými pravami nad aplikací.

V exceptions.xml se definuje ruční správa nad výjimkami. Jinymi slovy, pokud dojde k výjimce, mohu nechat aplikaci automaticky někam přesměrovat, odeslat příslušnou správu, atd. Samotná konfigurace může vypadat následovně:

V pages.xml se definuje page-flow. Zde je možnost využít klasický přistup přes navigation-rule v JSF nebo Seam přístup. Osobně se mi více zalíbíl tento přístup, jelikož povyšuje definici mnohem dál než v případě JSF.

V security.drl mám možnost definovat, nastavovat, odebírat, upravovat práva jednotlivých rolí. Jedná se o jakýsi konfigurační skript nad správou rolí. Pokud například chci, aby role admin mohla to samé co role obchodnik, žádný problém takovou věc nastavit.

Pro samotný běh enterprise aplikace je ještě zapotřebí nadefinovat jboss-seam.jar jako ejb modul. Definice se provádí v application.xml.

Pro práci s hibernate je zapotřebí nahrát všechny požadované knihovny do $GLASSFISH_HOME/lib a restartovat server.

Každý, kdo to s webovými aplikacemi v Jave myslí vážně, měl by se na Seam podívat. Už jen z prostého důvodu, že Gavin King se stal hlavním vývojářem pro novou specifikaci WebBeans, která by měla být v Java EE 6. Jak je patrné, tak WebBeans vycházejí právě z konceptu Seamu.

pátek 28. září 2007

NetBeans Platform (díl 2) – Výhody a nevýhody

Důvod, proč jsem zvolil desktop aplikaci vznikl z požadavku vytvořit aplikaci, která by komunikovala přes sériový port a ukládala čísla karet z různých čteček. Moc možností na výběr jsem neměl, jelikož přes webové rozhraní bych nebyl nic takového schopen aplikovat (samozřejmě nebudu zohledňovat aplety, které se mi dost příčí).

V první fázi jsem zvolil vlastní řešení (jako správný PHPčkář), přes Swing. Vše bylo v pořádku, do doby, kdy se aplikace začala rozrůstat. Implementace jednotlivých částí se prostě příliš svazovala mezi sebou a já začal mit v aplikaci chaos. Příčinou je jednak má nezkušenost s podobným druhem aplikací a jednak pouhá okrajová znalost konceptu pro distribuovanou Javu.

Poté jsem zajel na JAG, ve kterém se probírala RCP aplikace (NetBeans vs. Eclipse) a já si uvědomil, kde dělám chybu a jaké jsou výhody těchto řešení.

Asi bych měl znovu uvést, že se jedná o platformu, jinými slovy o „podvozek“, na kterém může běžet cokoli. Nejčastěji je ovšem známá kombinace: platforma + IDE = NetBeans IDE, Eclipse IDE. Dalo by se říci, že samotné vývojové prostředí je pouhý plugin dané platformy, i když je asi nejvýznamějším pluginem obou platforem.

Nyní již k samotným výhodám a nevýhodám tohoto řešení, do kterého zahrnuji kompletní řešení včetně použití dané platformy:

Z pohledu typu aplikace (desktop aplikace)

Výhody:
- možnost vytvořit přívětivé prostředí pro uživatele
- schopnost asynchroního volání bez zásahu nějakých zvláštních featur
- rychlá odezva mezi uživatelem a serverem
- prostředí umožňující přímou vazbu mezi uživatelem a OS (komunikace s periferiemi daného klientského PC)
- uvnitř desktop aplikace možnost používat i webovou aplikaci (vlastní web browser)

Nevýhody:
- distribuce (sice existují řešení jako JWS, ale s web aplikací se to srovnávat nedá)
- instalovana Java na klientském PC
- jisté systémové požadavky na běh aplikace (velikost RAM, atd)


Z pohledu architektury aplikace

Výhody
- swing (funguje kdekoli i s událostmi, na rozdíl od javascriptu u web aplikací)
- modulární systém (platforma stojí na tomto principu, který extrémně zpřehledňuje vývoj aplikace)
- skutečné OOP bez nutnosti statických view (HTML)
- Lookup (jedná se o hledání „služeb“ uvnitř kontextu NetBeans RCP)
- Services (služby, které lze registrovat a pomocí nich kominukovat mezi jednotlivými moduly, kteří o sobě vůbec nevědí, nemusí byt na sebe vázány)
- NetBeans API (při využívání tohoto API si navíc dokáži usnadnit práci a přímo ovlivňovat chování aplikace bez nutnosti přímého psaní swing komponent)
- podpora pluginů (pokud ve své aplikaci potřebuji nejakou funkčnost, kterou obsahuje plugin napsaný třetí stranou, mohu ho klidně využít a ušetřit si práci)
- celý koncept platformy, který je navržen tak, aby nejlépe odpovídal potřebám při psaní uživatelsky přívětivé aplikace

Nevýhody:
- náročná studie celého NetBeans API
- vzdálené volání EJB (spousta problémů při prvním setkání)
- v mnoha případech se jedná o kanón na vrabce

Asi by se dalo nalézt více kladů či záporů, ale v mém osobním pohledu, spatřuji tyto vlastnosti jako nejzásadnější.

V současné době se navíc musím vrátit k web aplikaci (osobně volím JSF), jelikož stojím před neřešitelným problémem: distribuce aplikace, s tím spojená i přímá aktualizace aplikace; a hardwarová náročnost aplikace, která mi neumožňuje distribuovat aplikaci mezi uživatele (velké fabriky holt nemají zájem tolik investovat do informatiky, kterou asi považují za nepotřebný subjekt).

I přes tuto velkou bariéru, mohu pokračovat na obou klientských verzích. Jak desktop, tak web, jelikož business logika (EJB kontejner) zůstává pro obě řešení stejná.

úterý 28. srpna 2007

NetBeans Platform 1. - Úvod

O co půjde?

Již podle názvu je jasné, že jsem se rozhodl psát o samotných NetBeans jako o platformě. V současné době se věnuji vývoji aplikace postavené právě na tomto "podvozku", a proto s tím souvisí i má snaha získat co nejvíce informací a zkušeností s touto platformou.

Předem bych rád upozornil, že nejsem žádný specialista v oblasti RCP aplikací, a proto se spíše budu zabývat menšími oblastmi při vývoji.

Často se mi stávalo, že jsem se v některé z pasáží natolik zasekl, že mi trvalo i několik dní, než jsem přišel na správné řešení. Jelikož jsem člověk, který rád pomáhá druhým, rozhodl jsem se, že touto formou pomohu některým lidem při jejich potížích.

Sám se budu snažit o zpětnou vazbu a pokud někdo bude znát lepší způsob implementace dané věci, budu rád, když ji poskytne ostatním.

Co byste si měli přečíst...

Jak už to tak bývá, tak i zde je třeba někde začít. Jistým předpokladem je znalost Javy, základní znalost swingu a znalost používání NetBeans jako vývojového nástroje.
Pokud všechny tyto znalosti mám, mohu se pustit do vývoje. Osobně jsem začal krátkými tutoriály na www.netbeans.org/, poté by měla být na řade kniha Rich Client Programming: Plugging into the NetBeans Platform.
Následuje Geertjan's Weblog, který popisuje jednotlivé postupy a nabízí srozumitelnější výklad než samotný javadoc.

Další zdroje se dají samozřejme nalézt pomocí googlu či na stránkách netbeans.org. Já se zaměřím spíše na základní popis.

NetBeans RCP

NetBeans IDE

Jako základní API jsem si zvolil NetBeans 6.0 M10. I když se jedná pouze o milestone, domnívám se, že se až tolik změn v API konat nebude. Proto všechny příklady budou předpokládát, že máte tuto verzi, či verzi vyšší, nainstalovánu.
Jelikož je spousta komponent přímo svázána (děděno z komponent Swingu ) se swingem, nebudu se příliš zaobírat jejich funkčností a budu předpokládat základní znalost těchto komponent.


Nakonec bych ještě jednou rád podotkl, že ne všechna řešení jsou v souladu se spravným použitím. Dost často se může stát, že bude existovat novější, efektivnější či odlišný způsob řešení daného problému. Proto mě prosím nekamenujte za tyto postupy, ale raději se pokuste přispět svými nápady v diskuzi.

NetBeans IDE

pátek 10. srpna 2007

Aplikace nezávislá na databázovém systému

V poslední době se dost rozrůstá názor, že aplikace by měly být psány tak, aby byly co nejvíce nezávislé na použitém DBMS. Osobně tento názor zastávám i já.

Důvodů je několik:

  • aplikace se může natolik rozsrůst, že stávající DBMS může být nevyhovující

  • vývoj v oblasti databází jde stále vpřed a s tím souvisí i změny v SQL jazyku

  • samotný model struktury dat by měl být definován v aplikaci, kde by měl být odstíněn od nějakého SQL

  • zdroje mohou být různé (databáze, soubory, vzdálená volání, ...)

  • aplikace může být vyvíjena bez použití databáze, která může přijít v pozdější fázi



Jak už to tak bývá, tak úspěch projektu je závislý od prvotní analýzy. Nechtějme tedy vše řešit hned od počátku. Jistě je bezpečnější si nechat otevřená zadní vrátka pro dané změny, které by mohly mít fatální následky.

Kompromis

Bohužel, nežijeme v ideálním světě, kde by vše bylo nalinkované tak, jak bychom si přáli. Uvedu jeden příklad, který mě přesvědčil o tom, že vytvořit aplikaci, která by byla skutečně nezávislá na DBMS je nemožné.
Pro načítání dat z jiných zdrojů, jsem použil Timer metody z EJB3, které mají tu vlastnost, že jsem schopný vytvořit si vlastní plánování plnění. Na persistenci jsem použil JPA. Když jsem zjistil, že JPA má možnost přiřadit listener na danou entitu, hned jsem si tuto vlastnost spojil s tím, že nebudu muset psát žádné triggery a hezky půjdu touto cestou.
To jsem si ovšem neuvědomil, že při dávkovém zpracování je JPA a EntityManager natolik náročný způsob, že jsem byl nucen přejít na nízkoúrovňové JDBC. Výhodou samozřejmě bylo extrémní zrychlení, ale nevýhodou, že daný Listener je v podstatě k ničemu. Ve finále jsem byl nucen napsat trigger a tím utnout možnost, že aplikační logika se postará o vše potřebné.


Vše není tak černé

I když jsem opustil snadnou přenostitelnost, stále mi zůstává možnost psát tu aplikaci tak, aby byl doménový model to hlavní a já byl co nejvíce odstíněn od DBMS. Přece jen, toho dávkového spracování zase není tolik, aby se to nedalo kdykoli změnit.
Používám 2 základní zdroje: MySQL a Oracle. Při klasickém přístupu jsou si obě databáze velice podobné. Je zde ovšem několik rozdílů, které jsou dost zásadní. Opět uvedu příklad, který toto vystihuje:
Chci nějaký základní reportovací nástroj, který bude pracovat tak, že uživatel napíše SQL dotaz, systém ho zpracuje a vrátí tabulku. Tabulku, která bude obsahovat možnost stránkování. A zde je ten problém, stránkování. U MySQL bych šel klasicky, přes: SELECT .... LIMIT x,y. Bohužel Oracle nic takového jako LIMIT nemá. Co teď? Parsovat SQL dotaz podle použitého DBMS? Ano. Ale s tím, že někdo něco takového již napsal. Samotný EntityManager obsahuje metody "setMaxResults(int arg)" a "setFirstResult(int arg)". Takže o jednu starost méně :)

Občas mi to přijde jako věčný boj. Každý druhý (v PHP) si píše vlastní databázové layery, tvrdí jak vše funguje, ale jen do doby, než přijde první požadavek, který nebyl očekáván podle specifikace používaného frameworku.

Doufám, že jednou bude svět natolik ideální, že skutečná nezávislost bude brána jako stadard pro psaní aplikací pro DBMS.

středa 25. července 2007

Novinky 1

Jelikož jsem v poslední době dost zaměstnán a nemám tolik času na psaní článků, rozhodl jsem se, že se alespoň občas pokusím sepsat pár novinek, které mne na internetu v poslední době zaujaly. Jedná se často o věci, se kterými mám osobní zkušenosti a mohu se výjádřit k jejich použití, či jsem do dané oblasti zainteresován.

Takže jedem...

JUG -Eclipse vs. Betbeans
První věcí je asi JUG, který měl jedno téma, a tím bylo Netbeans RCP vs. Eclipse RCP. Až bude k dispozici video, doporučuji ho stáhnout. Za oba tábory mluvili lidé, kteří jsou v této oblasti odborníci. Zejména Jarda Tulach, který je hlavním vývojářem NetBeans a zná tuto platformu do základů.

Eclipse 3.3 a PDT
Jistě spousta vývojářů zaznamenala, že vyšla nová verze tohoto oblíbeného nástroje a platformy. Nová verze nese označení Eclipse Europa. Současně s vydáním nové verze se i u ZENDu sebrali a provedli drobné úpravy svého PDT (PHP Development Tools) nástroje, který je nyní kompatibilní s novou verzí Eclipse. Samotná instalace je naprosto triviální. Stačí přidat do "Help -> Software Updates -> Find and install -> New features" nový remote site. URL adresa je http://download.eclipse.org/tools/pdt/updates/. Pro správné fungování je samozřejmě zapotřebí WST (Web Standard Tools).
Osobně jsem se hned pustil do aktualizace a nyní již na verzi 3.3 s PDT mohu opět fungovat.

NetBeans 6 M10
Ještě před vydáním Eclipse 3.3 vyšla nová milestone od Netbeans. Hned jsem tuto verzi vyzkoušel a i přes menší prodlevu při startu musím říct, že je verze naprosto stabilní. Změny se dočkala zejména textová část, která při psaní java kodu nabízí nové možnosti. Jednou z nich je i změněný přistup k refactoringu: Alt + Ins vyvolá popupmenu s možnostmi pro daný focus kurzoru. Další věcí, která mě potěšila, byla možnost přehazování a duplikování řádků (tak jak jsem byl zvyklý z Eclipse), pomocí Ctrl + Shift + (Up|Down) můžete řádky duplikovat a pomocí Alt + Shift + (Up|Down) řádky přesouvat. Zdánlivě maličkost, ale mně osobně udělala radost. Změn se dočkala i zvýrazněná syntaxe, kde je již možnost lepší orientace mezi klasickými parametry, které přišly z metody a mezi atributy třídy. Nezaznamenal jsem větší problémy, ba co víc, na této verzi stavím vlastní desktop aplikaci, která jde zatím také bez problémů.

phpMinAdmin
Poslední novinkou, kterou se zde budu zabývat, je nástroj od Jakuba Vrány phpMinAdmin. Na jeho webu se můžete dočíst, co ho vedlo k tomuto činu. Osobně si myslím, že pro malé projekty, které jsou poslány do víru internetu, je tento nástroj velice užitečný. Pokud stavíte menší aplikace a nemáte vzdalený přístup k MySQL, doporučuji se podívat, zda by Vám tato "malá aplikace" nepostačila. Samozřejmostí je zvážit phpMyAdmina, který je přece jen robustnějším nástrojem.

úterý 5. června 2007

OOP v PHP5 díl.7 - návrhové vzory (design patterns)

Při programování objektovým způsobem se dost často dostanete do fáze, kdy si nebudete jistí, jak máte danou třídu či samotnou práci s instancí provést. Může se jednat o triviální problémy typu: připojení k DB či složitější věci jako návrh MVC Frameworku.

Na tyto problémy mysleli čtyři chlapíci (Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides), kteří jsou autory knihy Design Patterns: Elements of Reusable Object-Oriented Software. Kniha se brzy stala natolik oblíbenou, že je dodnes povážována za nejlepší dílo ohledně OOP. Více o této historii se můžete dozvědět např. na Wikipedii.

Samotné návrhové vzory nejsou standardem, ale doporučením, jak při psaní máte postupovat. Já se nyní pokusím sepsat, jak je to
s návrhovými vzory v PHP. Vyberu jen ty nejjednodušší a nejčastěji používané a ukáži, jak je to s jejich implementací.

1. Singleton (jedináček)

Jak již název napovídá, jedná se o objekt, který je vytvořen pouze jednou. Tento návrhový vzor můžete využít například u připojení k databázi, kde si jasně řeknete, že byste neradi, aby Vám PHP otevíralo více spojení.

class Pripojeni {
private static $instance = null;
private function __construct() {}
public static function getInstance() {
if (self::$instance == null) {
$class = __CLASS__;
self::$instance = new $class;
}
return self::$instance;
}
}


Samotný fígl spočívá v tom, že instance samotného objektu je uložena jako statický atribut třídy a objekt je vytvořen pouze v případě, že je atribut null. Konstruktor třídy je nastaven jako private, aby se nikdo nemohl snažit vytvořit objekt pomocí new Pripojeni();. Samotní vývojáři v PHP ale přišli na to, že Singleton nelze na 100% vytvořit. Důvody proč tomu tak je, můžete najít v PHP dokumentaci, zejména v komentářích.

2. Factory

Tento vzor slouží k tomu, že vytvořím jednoduchou třídu, ve které vytvořím metodu, která podle přijímaného parametru vrací ten či onen objekt.

class Factory {
const MYSQL = "mysql";
const ORACLE = "oracle";
public static function getDBMS($dbms) {
if ($dbms == self::MYSQL) {
return new MySQL();
} else if ($dbms == self::ORACLE) {
return new Oracle();
} else {
throw new Factory_Exception("Neznamy ovladac");
}
}
}


Z kódu je jasné, že samotný vzor lze použít například k připojení na ruznorodé databáze.

3. Transfer object

Pokud skutečně chceme programovat objektově a programovat co nejefektivněji, nevyhneme se tomuto vzoru. Jedná se v podstatě o jednoduché třídy, které mají za úkol preprezentovat přenášená data. Nějčastěji se můžeme s tímto vzorem setkat v ORM nástrojích, kde jsou jednotlivé tabulky mapovány jako třídy a jedna instance je ekvivalentní jednomu řádku v databázi.

class Zamestnanec {
private $osobniCislo;
private $jmeno;
private $prijmeni;
/**
* @var Stredisko
*/
private $stredisko;
// ... setry getry


Často se také můžeme setkat s tím, že samotné objekty jsou příliš složité (tzn. odkazují se na další objekty jako v případě zaměstnance a střediska). Pokud se tak stane a naše aplikace přenáší velké množství dat, je nasnadě použít tzv. DTO (data transfer object), což je v podstatě jednoduchý objekt, který nemá jako atributy třídy další objekty, ale primitivní datové typy. V případě zaměstnance by to bylo číslo střediska, což je primární a unikatní klíč střediska. O tom, jak tvořit samotné DTO je spíše otázka té či oné aplikace a její složitosti a náročnosti.

4. Facade

Při vývoji softwaru se programátoři dostávali do situací, kdy potřebovali mít jednotlivé vlastnosti na jednom místě. Ať už z důvodu přehlednosti, rychlosti či provázanosti. Vzor facade řeší roztříštěnost vaší aplikace. Představme si, že máme vytvořit modul na správu zaměstnanců, která bude řešit jak editace zaměstnance, tak třeba i střediska. Jedna z možností je, že budeme zpětně složitě dohledávat objekty na editaci jednotlivých kategorií a nebo si vytvoříme jasně definovaná pravidla:
class ZamestnanecEdit {
public function add(Zamestnanec $zam) { /* prida zamestnance */ }
public function remove(Zamestnanec $zam) { /* smaze zamestnance - muze vyhodit vyjimku ZamestnanecEditException */ }
public function save(Zamestnanec $zam) { /* ulozi zmeny daneho zamestnance */ }
public function find($cisloZamestnance) { /* return Zamestnanec */ }
public function findAll() { /* vrati array vsech zamestnancu */ }
}


Tento jednoduchý objekt pracuje se zamestnanci. Třídu na editaci středisek si jistě dovedete představit. Nyní se vrátím k zadanému úkolu. Naprogramovat modul pro editaci zamestnance i s editaci střediska. Jedna z možností je, na view vrstvě volat tyto třídy pro práci a nebo si pěkne zhlukovat dané objekty do jednoho.
class ZamestnanciEditaceFacade {
/**
* @var ZamestnanecEdit
*/
private $zamestnanecEditace;
/**
* @var StrediskoEdit
*/
private $strediskoEditace;

public function __construct() {
$this->zamestnanecEditace = new ZamestnanecEditace();
$this->strediskoEditace = new StrediskoEditace();
}

public function addZamestnanec(Zamestnanec $zamestnanec) {
$this->zamestnanecEditace->add($zamestnanec);
}

public function addStredisko(Stredisko $stredisko) {
$this->strediskoEditace->add($stredisko);
}
// .....


Samozřejmě by se dalo najít spoustu příkladů použití. Pokud při programování někdo přemýšlí hlavou, dojde mu, že takto postupovat, znamená, že co nejvíce odstinuji view vrstvu od aplikační logiky.

5. Iterator

Posledním návrhovým vzorem, kterým se zde budu zabývat je Iterator. Již dříve jsem psal, že PHP 5 má k dispozici rozhranní Iterator, které podporuje tento návrhový vzor. Takže, oč jde. Nejednou se stane, že potřebujeme na určitou kolekci dat použít nejaký cyklus, ve kterém bych mohl daná data procházet. Na jednu stranu, mohu sice použít vlastní logiku na procházení daty, ale také mám možnost připravit si jakousi formičku pro určitá data, která se budou procházet. Příkladem může být, že vytvořím objekt s počátečním datumem (1.2.2007) a konečným datem (5.7.2007) a budu chtít daná data procházet po dni. Nebo budu chtít procházet písmena od B do X po jednotlivém pismenu. Na tyto a další operace se náramně hodí použít tzv. Iterator. Iterátor jako takový má podle interface přesně definované metody, které musí třída implementující rozhranní Iterátor obsahovat:

  • rewind() - nastavuje na první položku v seznamu

  • current() - vrací aktuální položku seznamu

  • key() - vrací klíč pole

  • next() - vrací následující položku seznamu

  • valid() - zjišťuje, zda existuje ještě nějaká položka


Podle těchto jasných pravidel jsem schopen vytvořit třídu, která bude procházet libovolný seznam dat podle určitých kriteríí či podle vlastní logiky. Velkou výhodou je znovupoužitelnost a také zapouzdřenost. Jiný programátor, kterému tuto třídu poskytnete vůbec nemusí vědět, jak daná logika pracuje, stačí, že implementuje Iterator a již je schopen, podle zadaných vstupních parametrů s třídou pracovat.

Návrhových vzorů samozřejmě existuje mnohem více. Navíc PHP je objektově dost omezené, takže ne vždy je zrovna ideální řešení právě ten či onen vzor. Někdy bývá lepší si některé věci prostě naprogramovat po svém. Na druhou stranu, bývá dobrým zvykem, že pokud se budu řídit určitými kriterii, které jsem v minulých článcích popsal, měl by vývojář míti klidné spaní. Na mysli mám zejména dodržování specifik jako jsou setry, getry, nazvosloví či dokumentace.
I když není objektově orientované programování zrovna jednoduchá záležitost, tak věřím, že pro nikoho není překážkou se základní principy naučit.

To by bylo k PHP asi tak vše. Jelikož jsem slíbíl, že daný díl dopíšu, stalo se tak. Nyní jsem již situován jiným směrem, takže PHP je pro mě pouze vedlejší záležitost. Přeji mnoho úspěchů při objektovém programování, ať už v jakémkoli jazyce.

Poslední radou by mělo být asi následující: OOP není cíl, ale prostředek k dosažení cíle. Proto neberte OOP jako něco spásného. Ba naopak, dost často se dostanete do problémů, které nebude jednoduché vyřešit.

středa 9. května 2007

Java EE 5 - MySQL -> Glassfish -> Swing díl 1.

V komentáři jsem dostal připomínku, že bych měl spíše napsat něco jednoduchého, co by pochopil i člověk, který o Jave a použitých technologií nic neví.

Rozhodl jsem se, že se pokusím sepsat "step-by-step" tutoriál, který by prošel základní vývoj jednoduchoučké aplikace v Jave.
Důvodem je možná i to, že aplikace psané v Jave, které mají míti třívrstvou architekturu client-server-databáze, nejsou jen o "core" programování. Mám na mysli nastavení, které není zrovna triviální. Možná i to je důvodem, proč někteří lidé skončí hned na startu.

Takže, co bude výsledkem:
Desktopová aplikace, která komunikuje s aplikačním serverem, obsahuje business logiku a je navázána na databázi přes daný server.

Jinými slovy, jedná se o třívrstvou architekturu klient-server-databáze. Za klienta si můžete dosadit jak webovou tak desktopovou aplikaci. Výhodou třívrstvé architektury je to, že klient neobsahuje aplikační logiku, která může být natolik náročná, že je lepší, aby ji spravoval výkonný server. Výhod je samozřejmě více, ale nám bude stačit tato základní.

Aplikace je celá psaná v Jave. Na klienta použiji Swing, který je součástí implementace Javy od SUNu a server bude glassfish (Java Sun Application Server 9), který je volně dostupný. Databáze bude MySQL 5.0.
Veškeré potřebné věci je možné získat zdarma, což je v dnešní době ohromná výhoda, zejména pokud si uvědomím, jakou možnost mi samotná Java EE 5 nabízí.

Co všechno budu potřebovat?


Instalace je jednoduchá. Nainstaluji uvedené produkty, tak jak jsem je vypsal. Pro počáteční start je to dostačující. Samotný MySQL Connector/J zatím uložím na disk, bude se hodit až v pozdější fázi.

V příštím díle ukáži, jak po instalaci nakonfiguruji základní parametry pro chod daných produktů.

pátek 27. dubna 2007

Java EE5 - stand-alone client

V minulém článku jsem nastínil, jakým způsobem se dá vyvíjet enterprise aplikace psaná v Jave. Samozřejmostí je využití různých metodik, podle kterých se řídí celý vývojový tým. Dříve, než mohu řešit rozsáhlé aplikace, musím ovšem míti dostatek zkušeností a znalostí. Já se chci více zaměřit na menší problémy, na které začátečník (stejně jako já) může narazit.

Budu předpokládat, že máte již základní znalosti o tom, co je to EJB, JPA a k čemu jsou enterprise aplikace určeny. Pokud by někdo hledal zdroj informací, osobně doporučuji tento tutoriál. Samotné čtení není nijak náročné. Předpokladem je základní znalost OOP, Javy, popřípadě databázových systémů typu Oracle, MySQL, .....

Osobně jsem si po přečtení celého tutoriálu udělal obrázek o tom, co je to vlastně Java EE 5 a k jakým účelům mohu něco tak rozsáhlého využít. V dnešní době je velký boom webových aplikací, které na nás srší ze všech stran. U samotné Javy se domnívám, že to není zrovna nejjednodušší oblast, kterou by se mělo začínat. Osobně jsem se raději více zaměřil na desktop, kde pomocí Swingu jsem schopen vytvořit "sexy" aplikaci, která bude splňovat základní podmínky. Každému, kdo s Javou začíná, doporučuji právě desktop.

Nyní již k samotné stand-alone aplikaci:

Přístup k EJB se dělí na dvě části:

  • Lokální (@Locale)

  • Vzdálený (@Remote)



O tom, který přístup daná EJB využívá se definuje anotací nad samotným interfacem, který samotná beana implemetuje:
@Remote
public interface UzivateleFacadeRemote {
public List findAll();
}


Rozdíl mezi Locale a Remote je ten, že Remote může volat aplikace, která běží v jiné VM. To se samozřejmě hodí ve chvíli, kdy potřebujeme napsat desktopovou aplikaci, která poběží na klientovi, který má vlastní instalaci JRE. Jiná VM není podmínkou pro běh Remote EJB.
Možná někoho napadne, proč tedy všude nevyužít Remote, když mohu volat tuto EJB kdekoli. Důvodem je výkon. Proto, pokud volám EJB uvnitř glassfishe (aplikační server), využiji k tomu Locale. Dost často mi z toho vychází, že implementuji obě interface na beanu. Navíc je také rozdílný způsob volání Locale a Remote EJB.

To by bylo k business logice. Vytvoříme si jednoduchou EJB, která bude mít Remote interface, kterou poté vystavím (deploy) na glassfish.

Nyní, se pustím do desktopové aplikace, která poběží na klientech a bude vzdáleně volat EJB ze serveru.

Prvním předpokladem je přidání celého EJB projektu v podobě distribuovaného jar souboru do aplikace. Jinými slovy, musí být někde, kde na něj samotná aplikace uvidí. V netbeans stačí do library includovat náš "projekt-ejb". Automaticky se hledá distribuovatelný jar soubor, který se defaultně nachází v adresáři dist.
Dále je potřeba přilinkovat tyto soubory:

  • appserv-admin.jar

  • appserv-deployment-client.jar

  • appserv-ext.jar

  • appserv-rt.jar

  • javaee.jar



Všechny uvedené soubory naleznete v adresáři instalovaného glassfishe (GLASSFISH_PATH/lib).

Tím bychom měli připravenou stand-alone aplikaci k tomu, aby nám byla schopna vzdáleně volat EJB.

Nyní již k samotnému kódu:
Properties properties = System.getProperties();
properties.setProperty("org.omg.CORBA.ORBInitialHost", );
properties.setProperty("org.omg.CORBA.ORBInitialPort", );
Context ctx = new InitialContext(properties);
// po pripravene inicializaci vzdalene zavolam EJB
UzivateleFacadeRemote facade = (UzivateleFacadeRemote) ctx.lookup("RemoteName");


Za a dosadíme vlastní parametry pro volání na server. Výchozím portem je 3700. Pokud testuji aplikaci na localhostu pod stejnou VM, jako mám server, není třeba properties nastavovat. Mohu zavolat InitialContext bez properties. Druhou možností je také nastavit parametricky tyto údaje. Pro další informace doporučuji glassfish: EJB FAQ.

Zapoměl jsem zmínit jednu důležitou věc. Pokud vzdáleně volám EJB, musím někde nastavit JNDI (název, pod kterým je vzdálená aplikace schopna nalézt EJB). Existuje několik možností, buď definovat daný název pomocí XML nebo pomocí anotací.

Záměrně jsem některé názvosloví popsal vlastními slovy. Důvodem je to, že při tak ohromném množství nových výrazů nejsem schopen se ihned orientovat. Také jsem ovšem danou problematiku nepsal stylem step-by-step. Zde by se jednalo o neštastné řešení, zejména ve chvíli, kdy se jedná o rozsáhlejší problematiku. Zde bych doporučil použít metodiku (pokus/omyl) :) Jinými slovy, bez přemýšlení není člověk schopen pochopit daný úkol.

Příště se podívám na JPA a FetchType. K čemu slouží LAZY a EAGER. A jak je to vlastně s defaultní hodnotou mimo a uvnitř glassfishe.

pátek 20. dubna 2007

Java EE 5 - začátky aneb konec PHP

Každý, kdo začně blíže studovat Java EE5, získá celkový přehled o tom, jak je Java rozdělena do několika vstev. Společně s tím, ale vyvstane spoustu otázek, jak provést to či ono. Některé věci totiž nejsou úplně zřejmé a pokud chci tvořit projekt, který bude provázán s dalšími vrstvami, dostanu se dost často do potíží s nastavením a vůbec spuštěním jednotlivých částí.

Na začátku je důležité si zvolit správnou technologii. Pokud zvolím Javu budu muset řešit další věc a tou je její ohromné množství frameworků. Osobně jsem toto vyřešil tak, že se držím (pokud je to jen možné) standardů SUNu.

Takže co je cílem: Vytvořit intranetovou aplikaci, která bude pokrývat požadavky firmy. Od výrobních procesů, přes ekonomické záležitosti až po různé schvalovací procesy. Klientem bude webová či desktopová aplikace. Ve chvíli, kdy potřebuji komunikovat se sériovým portem, musím volit desktop. Když budu řešit výpis sestav, použiji zase webovou aplikaci. Obě tyto aplikace musejí míti stejnou základnu (databázi). V lepším případě základnou bude business logika pro obě aplikace.

Jak jsem psal výše, zvolil jsem nejpoužívanější frameworky, které jsou navíc i standardy. Na persistenci (připojení k databázi) TopLink od Oracle. Jako databázi MySQL 5.0. Na namapování relačních tabulek do objektů JPA. Samotná business logika je řešena přes EJB3.0. Na webovou část jsem zvolil JSF společně s Facelets (i když Facelets není standard, dost pomáhá samotnému JSF). Na desktop Swing. Aplikační server je Sun Java Application Server 9 (glassfish).

Takže zvolené součásti mám úspěšně za sebou. Nyní přistoupím k samotné implementaci. První věcí, kterou musím udělat, je rozjet MySQL v glassfish. Toto udělám jednoduše tak, že nahraji java-mysql-connector do adresáře PATH_GLASSFISH/lib. V samotné admin konsoli (webová aplikace pro správu glassfishe), vytvořím connection pool a jdbc resource pro mysql a danou databázi.

Nyní přistoupím k tvorbě business logiky. Po vytvoření enterprise projektu ptovedu vytvoření persistence pomocí TopLinku. Po namapování glassfishe do IDE, vytvořím persistence.xml, který volá pomocí JNDI spojení s MySQL, kterou jsem v glassfish konsoli vytvořil.

Pro namapování relačních tabulek do JPA využiji požnosti IDE a nechám si je automaticky vygenerovat. Pro snadou správu samotných dat, vytvořím na klientovi nějakou CRUD aplikaci, takže si nechám vygenerovat i Session Beans z JPA. Použiji jak lokální, tak remote interface. Po tomto kroku, mám základ připraven. Mohu provést deploy na glassfish.

Nyní se pustím do samotného klienta. Nejprve desktopu. Vytvořím si samostatný projekt, do kterého nalinkuji potřebné glassfish knihovny a přilinkuji samotnou business logiku ve formě jar souboru. Pomocí vzdáleného volání, si nechám zavolat Session Beanu a již rovnou mohu pracovat s business logikou ve Swingu. K samotné distribuci swingové aplikace použiji Java Web Start.

Poslední věcí je webová aplikace. Přilinkuji JSF Framework, společně s Facelets. V Backing Beans volám Local EJB. Webová aplikace je v tomto ohledu o dost jednodušší, jelikož nemusím řešit vzdálené volání EJB, protože samotná aplikace běží na glassfish ve webovém kontejneru. Samozřejmě nezapomenu na convertery pro Entity a nastavení, jako navigaci, atd. Webovou aplikaci mohu vystavit na server.

Asi takto bych zjednodušeně popsal samotnou problematiku Enterprise Javy. Jako IDE jsem zvolil NetBeans a k deploymentu aplikací chytrého mravence (ant).

Tímto článkem jsem chtěl jen nastínit, že s PHP končím. Od dnešní doby se budu věnovat Javě či databázím. Pokud je někdo v podobné situaci jako já, přivítám jeho připomínky.


Příště se již budu věnovat něčemu přímočarému. Ukážu, jak ve stand-alone klientovi volat EJB z glassfishe. Na konci celý projekt zbuilduji a nechám poskytovat pomocí Java Web Start.

čtvrtek 12. dubna 2007

PDT a OOP

Každý, kdo chce efektivně pracovat s objekty, musí použít nástroj, který mu umožní automaticky doplňovat potřebné informace. Jinými slovy, použije nějaké IDE, které usnadní práci při psaní kódu.

Když si představím, že vytvořím objekt, který obsahuje několik metod, rád bych tyto metody rovnou volal. U jazyků, které dodržují striktně typovou kontrolu, je to jednoduché. Každý parametr metody musí mít typové označení, stejně tak návratová hodnota. U PHP je situace o dost horší. Jediné, co mi samotné PHP umožňuje je, že u parametru metody mohu definovat o jaký typ objektu se jedná. Navíc jsem omezen pouze na objekty a pole.
Jenže metody mi často vrací další objekty a tyto objekty někde dál používám. Samotný plugin od ZENDu (PHP Development Tool = PDT) na to jde od lesa. Dovolí mi používat komentáře, ve kterých si jasně definuji, o jaký typ se vlastně jedná. Lepší než další povídání bude ukázka.

class TridaA {
public function foo() {}
}
class TridaB {
private $tridaA;
public function __construct() {
$this->tridaA = new TridaA();
}
public function zavolejFoo() {
$this->tridaA->foo();
}
}


Z ukázky je jasné, že atribut třídy B je vlastně objekt z třídy A. Eclipse mi sice umožní automaticky zavolat metodu foo();, ale pouze v konstruktoru, protože dál už nevidí. V metodě zavolejFoo(); mám prostě smůlu. Mám ale možnost samotný atribut třídy okomentovat, čímž vyjádřím, že se jedná o objekt třídy A a pak již vše funguje, jak má.


/**
* @var TridaA
*/
private $tridaA;


Další věcí budiž parametry metody. Na začátku jsem psal, že PHP sice dovoluje definovat typ pro parametr metody, ale ne vždy tak činíme. Pokud typovou kontrolu na parametr metody definovat nechci, ale chci, aby Eclipse poznalo, že se jedná o tu či onu instanci objektu, jednoduše metodu okomentuji.


/**
* @param TridaA $tridaA
*/
public function setTridaA($tridaA) {
$tridaA->foo();
}


U definování samotného parametru metody je třeba mít na paměti, že musím také definovat, o jaký parametr se vlastně jedná.

Poslední věcí je návratová hodnota metod. K tomuto mohu opět použít komentář a říci tak Eclipse, o jaký návratový typ se vlastně jedná.


/**
* @return TridaA
*/
public function getTridaA() {
return new TridaA();
}


Pokud tedy pracujete s objekty a používáte k tomu jazyk, který má dynamické typování, jistě Vás často naštve, že nevíte, co vlastně v danou chvíli proměnná obsahuje. Toto Vám sice nezaručí, že nebudete chybovat při zjišťování typů, ale zaručí, že samotné programovací prostředí Vám řekne, co teď vlastně používáte.

Jestli jste neměli v oblibě komentáře, tak nyní si je určitě zamilujete :)

O psaní komentářů by se dala napsat celá kniha, ale o tom zase jindy.

středa 4. dubna 2007

JSF & Facelets

Samotné JavaServer Faces (JSF) je ve své podstatě jednoduchý framework na view vrstvu, který komunikuje pomocí Backing Beans. JSF v žádném případě neruší metodiky JSP-Servletů, pouze je potlačuje ve prospěch vývojářů a snaží se nabídnout alternativu pomocí JSF.

V JSF je několik vlastností (zejména uvnitř faces-config.xml), které jistě stojí za to prozkoumat:

  • Navigace

  • Lokalizace a vlastní definice messages

  • Definice managed-beans (request, session) ...

  • Psaní HTML komponent v pomocí jsf/html

  • Tvorba vlastních UI komponent



Pro vývojáře, kteří mají s podobnými typy frameworků již zkušenosti, jistě není problém se JSF doučit. Ve chvíli, kdy je pro Vás jsp-servlet nový pojem, doporučuji rovnou začít na JSF. Samotná metodika Vás nakonec stejně donutí se jsp-servlety částečně doučit.

Když to vezmu do důsledků, tak jako vývojář v PHP jsem měl k jakýmkoliv frameworkům odpor. Ne snad z toho důvodu, že bych si raději všechno psal sám, ale z toho důvodu, že jsem nikdy nevěřil, že ten či onen framework bude i nadále podporován a že mi poskytne komplexní řešení.
U JSF je situace jiná. Samotný framework (stejně jako např. JavaPersistence API), je standardem SUNu, což samo o sobě dává pocit jakési jistoty, že se samotné API neučím nadarmo. Mám jistou záruku, že bude více využíván, dále podporován, či na něm budou postaveny další implementace, které se budou snažit dodržet standard a k tomu použiji své vlastní rozšíření.
Takovouto podobnost mohu nalézt např. mezi JPA a Hibernate, kde Hibernate se stalo plně kompatibilní s JPA a navíc nabízí vlastní rozšíření (např. CriteriaAPI).

Abych jen neházel samou chválou, přece jen mně na JSF trochu vadila jedna věc a to je "šablonovací systém". Nebo chcete-li, možnost, kdy budu vkládat své stránky do stejné "formičky".

Nakonec jsem našel "Facelets", což je v podstatě rozšíření samotného JSF, které je ovšem zaměřeno právě na šablonovací systém. Samotný popis lze nalézt zde.
Pro NetBeans existuje i vlastní plugin, který je popsán zde.

Takže pokud někdo začíná s webovými aplikacemi v Jave, doporučuji JSF-EJB3-JPA. I když není Java EE 5 zrovna jednoduchá záležitost (alespoň pro mě), tak stojí za to alespoň nahlédnout, jak vlastně taková architektura vícevrstvé aplikace (z pohledu Javy), vypadá.

Na webu Jakuba Vrány o PHP, se někteří lidé domnívali, že URL v JSF je statická. Na malý problém existuje malá náplast a tou je "" v navigation-case. Stejnou fintu je třeba použít, pokud budu tvořit zabezpečenou aplikaci přes url-pattern (/secure/*) v security-constraint.

úterý 27. března 2007

OOP v PHP5 díl.6 - viditelnost a klíčová slova

Pokud budeme mluvit o objektech jako o zapouzdřených componentách, musíme nějakým způsobem zajistit, aby daná komponenta poskytovala jen to, co skutečně má. Pokud bychom ignorovali viditelnost jako takovou, vznikl by nám mezi jednotlivými třídami chaos, který by zapříčinil nepoužitelnost.

Vezmu to pěkne od začátku, mám atributy třídy a metody třídy. Obě tyto vlastnosti každého objektu mají volitelnou viditelnost, která je rozdělena do tří úrovní:

  • public

  • protected

  • private



Public
Jakákoli vlastnost objektu nastavená viditelností public mi umožňuje říci, že: "každý má právo k této vlastnosti přistupovat".

Protected
Narozdíl od public, má protected omezení jen na viditelnost v samotné třídě a třídách, které jsou potomkem.

Private
K vlastnostem označeným jako private může přistupovat pouze a jedině vlastní třída.

Když jsem v minulých dílech tvrdil, že atributy třídy by měly být označeny vždy jako private, neříkal jsem úplně pravdu. Při tvorbě vlastních tříd se dost často setkáme s problémem, kdy bych potřeboval použít daný atribut jako parametr metody. Jinými slovy řečeno, podle parametru mi metoda vykoná to či ono.

class HTML_Form_Input {
private $value;
.....
public function __construct($value) {
$this->value = $value;
}

public function setValue($value) {
$this->value = $value;
}

public function getValue() {
return $this->value;
}
.....
}


Tato jednoduchá třída implementovala private jako viditelnost pro atribut třídy a public jako atribut pro konstruktor a setry a getry. Teď ovšem nastává problem, kdy bych potřeboval identifikovat typ samotného inputu. Jedna z možností by byla, že bych metodě setType(String) vždy posílal vlastním stringem, o jaký typ se vlastně jedná. Toto sice lze, ale my se budeme snažit o co nejlepší znovupoužitelnost a možnost nastavení těchto typů přímo ve třídě, abychom nemuseli při refactoringu dohledávat všechny různé překlepy, atd.

class HTML_Form_Input {
const TYPE_HIDDEN = "hidden";
....
}
$input = new HTML_Form_Input("jmeno");
$input->setType(HTML_Input_Form::TYPE_HIDDEN);


Konstanta jako taková je neměná a je přístupná mimo vytvořený objekt. Pokud bych chtěl danou konstantu volat přímo ve třídě, využiji k tomu self::.

S dalším klíčovým slovem, se kterým se můžete setkat, je static. Statický atribut či metoda je taková vlastnost, která mi zapříčiní, že ji mohu získat aniž bych musel vytvářet objekt. Její hodnota je tedy nezávislá na tom, zda objekt existuje či nikoli. Pokud bych to převedl do praxe, můžu pomocí statického atributu třídy zjišťovat, kolikrát jsem vytvořil objekt z dané třídy.

Další ukázky si nechám do příštího dílu, který budu věnovat Design Patterns, neboli návrhovým vzorům. Ukážu např. implementování Iteratoru, který lze nativně v PHP 5 nalézt.

pondělí 19. března 2007

PHP & Java: SHA-1

Při vývoji javovské aplikace jsem narazil na problém autentifikace uživatelů. Problém spočíval v tom, že mám tabulku uživatelů, která obsahuje hash hesla, který je hashován pomocí PHP.

echo sha1(sha1("heslo"));


Čekal jsem, že v Java API naleznu podobnou metodu na hash Stringu, bohužel jsem hledal marně :)

Jelikož jsem si nevěděl rady, poprosil jsem na konferenci na java.cz o malou pomoc. Po odpovědi obsahující link, na tvorbu hashe ze Stringu, jsem moc moudrý nebyl :(
Potom jsem dostal ovšem odpověď v podobě třídy, kterou jsem nakonec po své úpravě byl schopen aplikovat.

package org.dostal.dochazka.crypt;

import java.security.MessageDigest;
/**
* Statické metody pro výpočet hash
*
* @author Ales Dostal;
*/
public class HashUtil {

public static final String HASH_TYPE = "SHA-1";

/**
* konstruktor
*/
private HashUtil() {}

/**
* vypocita SHA-1 hashovaci klic z byte[] a vrati jej jako HEXa retezec
*
* @param pass heslo ve String
* @return HEXa řetězec
*/
public static String SHA1AsString(String pass) {
return SHA1AsString(pass.getBytes());
}

/**
* vypocita SHA-1 hashovaci klic z byte[] a vrati jej jako HEXa retezec
*
* @param pass heslo v byte[]
* @return HEXa retezec
*/
public static String SHA1AsString(byte[] pass) {
return hex(SHA1(pass));
}

/**
* vypocita SHA-1 hashovaci klic z char[] a vrati jej jako HEXa retezec
*
* @param pass heslo v char[]
* @return HEXa retezec
*/
public static String SHA1AsString(char[] pass) {
return SHA1AsString(String.valueOf(pass));
}

/**
* Vypočte SHA-1 hashovací klíč z řetězce
*
* @param secret pomocný klíč
* @return pole bytů
*/
private static byte[] SHA1(byte[] pass) {
byte[] mac = new byte[20];
try {
MessageDigest sha = MessageDigest.getInstance(HASH_TYPE);
sha.update(pass);
mac = sha.digest();
} catch (Exception e) {
e.printStackTrace();
}
return mac;
}

/**
* Převede pole bytů na HEXa řetězec.
*
* @param data pole bytů
*/
private static String hex(byte[] data) {
StringBuilder sb = new StringBuilder();
for (byte b : data) {
sb.append(Character.forDigit((b & 240) >> 4, 16));
sb.append(Character.forDigit((b & 15), 16));
}
return sb.toString();
}

}


Nyní jsem schopen přistupovat k porovnání hashe jak z PHP, tak z Javy. Sice je to taková maličkost, ale občas dost důležitá :)

echo sha1("heslo");

System.out.println(HashUtil.SHA1AsString("heslo"));

úterý 6. března 2007

OOP v PHP 5 - teorie dědičnosti a ORM

Když se vrátím na začátek, kde jsem tvrdil, že objekty jsou jakýsi obal nad procedurálním kódem, tak se musím zamyslet nad tím, jak umožnit, abych nemusel stále dokola zabalovat jednu a tu samou věc. Třídy bych měl vždy navrhovat tak, aby obsahovali jen to nejnutnější a nebyly zbytečně vázany na jiné třídy. Navíc třídy by něměli obsahovat pevnou vazbu na třídy, které jsou navrženy v jiných úrovních.

Příklad:
Do třídy pro zobrazení stromové struktury nebudu cpát třídu, která mi vrací data stromu. Raději ve třídě stromu napíši metodu, která bude umět přijmout data a zobrazit je. Na získání dat vytvořím jinou třídu.
Když budu později potřebovat zobrazit strom s jinými daty, prostě použiji již hotovou třídu stromu, která přijímá data.


Tím dokážu vytvořit znovupoužitelný kód. K tomu, abych mohl takto tvořit třídy, ale musím znát všechny možnosti objektů. Nyní se vratím k další možnosti objektů a tou je dědičnost.

Dědičnost je vlastnost, která mi umožňuje rozšířit třídu a pozměnit její chování. Nic víc, nic míň.

Na začátku jsem napsal, že třídy by měli být co nejořezanější, neměli by obsahovat věci, které by ji svázali natolik, že by obsahovala zbytečné a nevyužitelné vazby. Pokud ovšem v projektu potřebuji danou třídu rozšířít a to tak, že dané rozšíření budu využívat vícekrát, prostě napíši si novou vlastní třídu, která bude dědit vlastnosti z minulé třídy.

Příklad:
Mám třídu na zobrazování filtrace nad daty. Teď je ovšem problém, že v některých případech filtruji přes ty samé položky (př. název). Jednou možností je, pořád do objektu posílat objekt (komponentu) název. Jelikož už vím, co je dědičnost, mohu ji využít. Vytvořím novou třídu, která bude dědit třídu filtrace a navíc bude automaticky vkládat komponentu pro název.


Toto je jedna z možností jak dědičnost využít, přiznávám, že ne moc efektivní, jistě existují i jiné možnosti, ale jako příklad je to postačující.

Asi lepším příkladem je struktura dat v databázi. Dnes jsou nejrozšířenejší relační typy databází. Jistě jsou velmi efektivní, rychlé a snadné na práci, ale pro nás jsou dost nevyhovující, proto existuje ORM (objektově relační mapování), což není nic jiného, než, že tabulku v databázi převedeme na objekt.

CREATE TABLE zamestnanec (
cislo int NOT NULL,
jmeno varchar(100) NOT NULL,
prijmeni varchar(100) NOT NULL,
PRIMARY KEY(cislo)
);



class Zamestnanec {
private $cislo;
private $jmeno;
private $prijmeni;
/* + setry a getry ke vsem atributum */
}


Nyní vytvoříme tabulku "uzivatele". U uživatelů budeme potřebovat navíc heslo, počet přihlášení, poslední přihlášení. V databázi tedy vytvoříme tabulku "uzivatele", která bude mít primární klíč osobní číslo, které bude zároveň cizím klíčem s vazbou do tabulky zaměstnanců na osobní číslo.

Potom pro výpis uživatelů použijeme něco takového:
SELECT u.*, z.jmeno, z.prijmeni
FROM uzivatele u
INNER JOIN zamestnanci z ON u.cislo = z.cislo


To je v pořádku, databázi máme, ale jak to uděláme v našem projektu, kde máme objekty? Velice jednoduše, použijeme dědičnost.

class Uzivatel extends Zamestnanec {
private $heslo;
private $pocetPrihlaseni;
private $posledniPrihlaseni;
/* setry a getry */
}


Nyní jsem vlastně rozšířil zamestnance o další atributy aniž bych musel znovu psát jeho vlastnosti (např. v Jave na toto existují tzv. entity classes, u nich by bylo toto rozdělení více podobné struktuře DB, což v PHP zařídit jen tak nepůjde). Dědičnost se definuje tak, že mám jednoho předka, který obsahuje vlastnosti, které se mi budou hodit i ve třídě, která je dědí. Pokud by se mi stalo to, že budu dědit z třídy, která obsahuje vlastnosti, které nebudu nikdy potřebovat, je dědičnost navržena špatně.

Tento článek berte spíše s nadhledem, opravdu se domnívám, že dědičnost je tak záludná záležitost, že bych se na ni na začátku úplně vykašlal. V pozdějších článcích se k tomto tématu vrátím a ukážu, jak něco takového využít v praxi. Příklady, které jsem zde uvedl nejsou úplně nejtypičtější, ale jistě lepší, než ukázky typu: Matka => Dcera, které postrádají použitelnost v praxi.

Příště už o něčem jednoduchém, viditelnosti a klíčových slovech static, final, apod.

neděle 4. března 2007

Proč jsem tolik nadšený z Javy?

Jako každý správný programátor jsem i já velice líný člověk. Ano, přehnanou pílí z Vás programátor nikdy nebude. Důvodem není to, že by programování byla jednoduchá věc, kterou se stačí naučit a pak jen aplikovat, ale proto, že hledáte stále lepší a lepší řešení, které by Vám usnadnilo další vývoj.

Když to převedu do praxe:
Představte si, že vedle sebe posadíte 10 lidí (kteří mají základní znalosti s prací na PC) a dáte jim za úkol napsat v Excelu čísla od 1 do 30. První skupina lidí si sedne a začne psát čísla od 1 do 30. Možná budou i rychlejší, jelikož nemusí nad ničím přemýšlet. Druhá skupina lidí si řekne, že je to moc práce a začne hledat způsob, jak si práci usnadnit. I když zadaný úkol nestihnou v časovém limitu, budou jistě produktivnější. Jen si představte, že byste po těch pracovitých lidech chtěli, aby Vám napsali čísla od 5 do 1000. Kdo myslíte, že poté zvítězí? :)


Tímto příkladem jsem chtěl jen nastínit, že programování není o velké dřině, ale o neustálém přemýšlení nad tím, jak si svou práci co nejvíce usnadnit a zároveň přizpůsobit natolik, abych při nějaké změně nemusel brečet u šéfa, že je to strááášně složité a v podstatě nemožné :)

Vrátím se ale zpět k tématu tohoto článku. Proč jsem vlastně tak moc nadšený z Javy?

Důvod jsem již popsal, jsem líný člověk a nechci svůj mozek vyčerpávat věcmi, které jsou jednoúčelové. Stále porovnávám Javu s PHP. Vím, že porovnávat tyto dvě odlišné technologie je nesmysl, ale toto srovnání dělám na základě vlastních zkušeností a snažím se porovnat jejich použitelnost pro mou práci.

Po získání základních znalostí o objektech jsem měl v PHP problém je nějakým způsobem aplikovat do praxe. Základní API je celé procedurální a v rozjetém projektu jsem nebyl schopen nasadit žádný PHP framework, který by mi mohl mou práci usnadnit. Vydal jsem se vlastní cestou a napsal si svůj vlastní framework na ORM, DAO, Models, Views. Sice nic extra, ale pro mé účely postačující. Jenže... Co dál můžu v PHP chtít dělat, když jsem vázaný na webový kontejner Apache httpd, který musí být navíc natolik odlišně nakonfigurovaný, že se z aplikace stějně stal nepřenositelný moloch. Navíc další využití v menších projektech bylo téměř nulové. Práce s daty také žádný šlágr. Stálé psaní toho samého. Ani IDE (Eclipse a PDT) neposkytuje takový komfort jako v jiných jazycích.

Objekty jsem se hned od začátku učil na Javě, takže jsem věděl, že je to jazyk, který se drží nějakých zásad a má striktní typovou kontrolu, která mě drží na správné cestě a nevede do slepých uliček. Osobně jsem se ale do vývoje v Javě bál více pustit, protože přece jen nejsem žádný guru v oblasti objektů a programováním se zabývám tak 3 roky. Jenže teď jsem v práci dostal za úkol udělat aplikaci na tištění nějakých kartiček, která by běžela pouze na jednom PC a nebyla přes http.

Tak jsem se teď více vrátil k Javě a dělám Swing aplikaci, kterou mám z větší části hotovou. Když jsem zjistil, že mohu použít JPA i ve standalone aplikaci, byl jsem nadšený. Vím, že pak mohu vzít část tohoto projektu a rozjet ho jako webovou aplikaci. Mohl bych toto udělat v PHP? Asi ano, ale dělat v PHP pod GTK by byla jistě dobrá onanie.

I když nejsem žádný přeborník v Jave a většinu věcí zatím dohledávám po netu či píšu na konferenci na java.cz (za odpovědi ještě jednou děkuji), tak jsem schopen všechny překážky přeskočit (ovládání swing aplikace přes události, tisk, napojení na MySQL, atd. atd.), což mě vede k závěru, že už mi chybí jen zkušenosti, abych byl více produktivní v tomto jazyce.

Nadšený jsem zejména z věcí jako je Java Persistence API, díky čemuž objektově namapuji relační databázi a pak již pracuji s objekty a všemi základními vlastnostmi jako je dědičnost či polymorfismus. Navíc nemusím nic definovat v XML, ale hezky si tvořím anotace. Další věcí budiž Swing pro desktop, který je pomocí NetBeans tak snadno naklikatelný, že se jedná spíše o malý Photoshop :). JSF framework pro web. aplikaci mi zejména po použití navigátoru a různých vlastních komponent přišel jako geniální nástroj pro web. Také celé API Javy je natolik rozsáhlé, že snad všechno je v něm již implementované. Samotné standardní frameworky od Sunu jsou na tolik dobré úrovni, že zatím nepotřebuji nic jiného.

Co se týče vlastních zdrojů, musím zde ještě jednou zmínit portál java.cz a jeho emailovou konferenci. Jsem rád, že jsou zde inteligentní lidé a neřeší se zde věci typu: jak vypsat hello world. Dalším dobrým zdrojem jsou přednášky o Javě, které lze nalézt na http://avc.sh.cvut.cz. Než je člověk schopný začít číst z manuálu, také doporučuji tutoriály na netbeans.org. Ukázkové příklady lze nalézt na http://www.exampledepot.com/egs/index.html.

Zdrojů je vážně spousta, člověk musí jen hledat :)


Dobrým zdrojem informací jsou samozřejmě také knihy. Osobně jich o Javě vlastním pět. Ale o těch zase někdy příště. Tak co? Už jste dopsali čísla od 5 do 1000? :)

pondělí 12. února 2007

OOP v PHP 3 - interface

Interface (rozhranní) je jedna z věcí, která je často přeceňována nebo nedoceňována. Oč vlastně jde?

Představte si, že se dostanete do situace, kdy budete potřebovat určit, že objekt "umí" něco, co se od něj očekává, ale nejsme si jistí, zda to tak je :)

Uvedu příklad:
Mám objekty manželka, děti, papoušek, pes a tchýně. Všechny objekty mohu považovat za součást rodiny. Problém nastává ve chvíli, kdy bych potřeboval vědět, kdo z uvedených rodinných příslušníků umí vařit. Vaření si mohu představit jako metodu, která mi provede danný úkon a vytvoří (vrátí) objekt jídlo.

Toto je klasický příklad, kdy mohu použít (implementovat) interface. Nejdříve si vytvořím vlastní interface, které bude obsahovat metodu uvarJidlo().

interface UmiVarit
{
public function uvarJidlo(Jidlo $jidlo);
{
?>


Nyní mám rozhranní, které je potřeba implementovat na ty třídy, které budou moci vařit jídlo.

class Manzelka implements UmiVarit
{
public function uvarJidlo(Jidlo $jidlo)
{
return "manzelka uvarila: ". $jidlo->getNazev();
}
}?>


Takže nyní, když zavolám objekt (rodinného příslušníka), jsem schopen určit, který z nich vařit umí a který nikoli.

$rodina[] = new Manzelka();
$rodina[] = new Tchyne();
$rodina[] = new Pes();
foreach($rodina as $val) {
if($val instanceof UmiVarit) {
echo "umi varit: ". $val->uvarJidlo(new ChlebaVeVajicku());
}
}
?>


Interface můžete chápat jako svou vlastní kontrolu, kde si programátor označuje jednotlivé třídy podle toho, co mají umět. Myslím si, že úplnému pochopení, k čemu vlastně interface mohu využít a jak použít je otázkou praxe. Jak se říká: nic se nemá přehánět. A to platí i zde. Na druhou stranu, ignorace implementování rozhranní vede k chaosu a nižší funkčnosti.

Co se týče pravidel, jsou zde jasně danná specifika:

  • interface může obsahovat konstanty a veřejné metody

  • třída implementující interface musí obsahovat metody podle interface

  • třída může implementovat více rozhranní, které se oddělují čárkou (např. UmiVarit, PrepinaTelevizi)



Samotné PHP obsahuje několik předdefinovaných rozhranní, z nichž nejzajímavější je Iterator.

Tak by bylo k interface vše. Samozřejmě, dalo by se zde napsat spoustu dalších možností a využití, ale stačí, když si budu pamatovat, že Interface usnadňuje a označuje třídy tak, abych byl schopen použít jejich specifické vlastnosti.

Příště již ke zmíněným abstraktním třídám a dědičnosti, která je asi tím nejsložitějším tématem v OOP vůbec.

úterý 30. ledna 2007

OOP v PHP 2 - základy

Minule jsem ukázal základní vlastnosti OO kódu. Dnes se pustím do bližší specifikace, základů psaní OO kódu.

Na začátku je dobré brát v potaz, že OO kód by měl být samodokumentovatelný. To znamená, že kód je srozumitelný nejen pro počítač, ale také pro člověka. Pokud budu vycházet z tohoto základu, tak mi z toho vychází, že budu muset dodržovat základní principy při psaní OO kódu.

Začnu pěkne od začátku:

Třídy:

Název třídy se vždy uvádí velkým písmenem.
Název třídy je podstatné jméno, nikoli sloveso.
Pokud název třídy obsahuje více slov, používá se tzv. VelbloudiNotace.

Další důležitou roli hraje samotný název, který by neměl kolidovat s jiným názvem třídy. Ve skutečných OO jazycích je toto řešeno pomocí např. balíčků (packages) v Javě. Samotný balíček má i další vlastnosti, ale nám by stačilo, kdyby v PHP existoval alespoň v základní úrovni. Uvedu název balíčku, do kterého danná třída spadá a když budu potřebovat někde vytvořit objekt z této třídy, uvedu název třídy i s balíčkem. Název balíčku vlastně odpovídá adresářové struktuře, kde je má třída uložena (např. org.dostal.Zamestnanci by bylo v adresáři /org/dostal/Zamestnanci.class). Krásné, že?

Bohužel PHP nic takového nemá. Proto je třeba volit jiný postup. Budeme vycházet z toho, že třídy vkládáme do vlastní adresářové struktury a tuto strukturu odvodíme pomocí názvu třídy. Jako oddělovač jsem zvolil "_", což asi nejlépe odpovídá tomu, jak identifikovat strukturu, kde mám třídu uloženou.

Příklad:
Vytvořím adresar "Model", do něj vytvořím adresář "Table". Poté vytvořím soubor s názvem "Filtr.php". Nakonec do souboru vytvořím třídu "class Model_Table_Filtr {}". Díky tomu jsem schopný identifikovat, kde třída "Filtr" vlastně leží.

Další zásadou je, že jeden soubor = jedna třída. Nemá smysl o tomto polemizovat, je to způso, který se osvědčil nejenom v PHP.

Atributy tříd:

Atributy tříd by měly být vždy zapouzdřené, jinak řečeno, zvenku by k nim měl existovat pouze přístup přes setry a getry.
Atribut třídy začíná malým písmenem a pokračuje opět velbloudí notací.
Toto do začátku stačí.

Metody:

Název metody začíná vždy malým písmenem.
Opět se využívá velbloudí notace.
Název metody by mělo být sloveso (např. filtruj, zobraz, atd.), samozřejme to neplatí vždy.
Metody začínající na set... jsou setry, nastavující nějakou hodnotu.
Metody začínající na get... jsou getry, vracející nějakou hodnotu.
Metody začínající na add... přidávají k nějaké hodnotě, další hodnotu.
Metody načínající na is.. jsou kontrolní a vracejí Boolean (true, false) hodnotu.
Metoda toString() vrací informaci o třídě.
Existují další metody, tzv. magické metody začínající dvěma podržítkama, které proberu později.
Jsou i jiné specifika, které teď nemá cenu rozebírat, pro začátek toto stačí.

I když jsou tyto informace dost nudné, jsou velice důležité pro další vývoj v objektově orientovaném programování.

Existuje spoustu doporučení a spousty standardů, čeho se držet, ale já vycházím z javovské konvence, která mi osobně přijde nejlepší.

Nyní opět malá ukázka toho, jak by měl vypadat standardní OO kód.

class Auto
{
private $barva;
private $rychlost = 0;

public function __construct() {}

public function setBarva($barva)
{
$this->barva = $barva;
}

public function getBarva()
{
return $this->barva;
}

public function setRychlost($rychlost)
{
$this->rychlost = (int) $rychlost;
}

public function getRychlost()
{
return $this->rychlost;
}

public function isRychlost()
{
return (boolean) $this->rychlost;
}
}
?>


Příště už se pustím do samotného programování a proberu věci jako: typová kontrola, abstraktní třídy nebo interface.

pondělí 29. ledna 2007

OOP v PHP 1.

Spousta lidí tvrdí (stejně jako já), že psát objektově v PHP je šílenost a samotné PHP nemá tak dobrou podporu ani model k objektovému přístupu. Koncepce tohoto skriptovacího jazyka je postavena tak, abych byl schopen co nejrychleji nabastlit kód, který je schopen funkčního nasazení. Přesto je zde možnost psát objektově a od verze 5 dokonce i s vlastnostmi blížícími se objektově orientovaným jazykům typu Java či C++.

Předtím, než mohu začít psát objektově, musím mít elementární znalosti o tom, co jsou objekty, instance, jak funguje dědičnost, apod. Pokusím se zde popsat tyto znalosti tak, abych byl schopen na nich stavět.

Dost častá chyba je, když programátor pochopí OOP jako něco složitého či nereálného k použití. Ještě větší chybou je, když vývojář začne stavět projekt na objektech, aniž by měl dostatek znalostí k tomu, jak efektivně využít všech vlastností (toto byla i má chyba).

Takže o co vlastně jde? Na začátku můžete objekty chápat jako balíčky, které obsahují funkce a promenné, s kterými se dá pracovat v zájmu balíčku (objektu). Jinými slovy řečeno: "Objekty jsou obal nad procedurálním (obýčejným) kódem.".

OOP obsahuje spoustu nového názvosloví, které je potřeba znát, abych byl schopen rozluštit, o čem se dva objektoví programátoři mluví :)

// toto je trida
class Zamestnanec
{
// toto je atribut tridy
private $cislo;

// konstruktor tridy
public function __construct() {}

// metoda tridy
public function setCislo($cislo)
{
$this->cislo = $cislo;
}

// metoda tridy
public function getCislo()
{
return $this->cislo;
}

}
?>


Pokud má třída metody začínající set či get, tak je nazývame jako setry a getry. Tyto setry a getry nastavují a vracejí hodnoty, respektive pracují s atributem třídy, který by se měl vždy definovat jako "private".

Tímto jsem popsal základní názvosloví kolem třídy. V druhém kole popíši, jak třídu použiji.

$z = new Zamestnanec();
$z->setCislo(123);
echo $z->getCislo();


Takže, co je co? :) Promenná $z můžeme nazvat instancí objektu. Instance je jinak řečeno odkaz na objekt. Objekt je "new Zamestnanec()". Někdo by si zde mohl myslet, že objekt poznám tak, že obsahuje "new", ale není toúplně tak pravda. Např. objekt může být vytvářen jako jedináček (Singleton), který může být vytvořen pouze jednou. Takový objekt se vytváří interně a proto ho zvenku nevytvářím pomocí new (o tom, ale až později).

Dále je vidět, že pomocí instance (odkazu na objekt) volám metody set a get. Z vnějšku mohu volat pouze metody, které jsou public (veřejné). Důvody, proč je něco private, něco private a něco public, popíšu později.

To by bylo do začátku asi vše. Byli byste nyní schopni napsat třídu Auto obsahující atribut rychlost a metody na nastavení a vrácení rychlosti? Stejně tak i tuto třídu použít? ;)