Přejít k navigační liště

Zdroják » Různé » Java na webovém serveru: první web

Java na webovém serveru: první web

Články Různé

Minule jsme řešili spíše administrativní záležitosti. Dnes se podíváme na hlavní komponenty, ze kterých se webová aplikace psaná v Javě skládá, Seznámíme se se základy JSP a JSTL. Probereme podrobněji deployment. Naučíme se ošetřovat HTML výstup a nastavit si vlastní chybové stránky.

Nejdříve si synchronizujeme zdrojové kódy našeho programu a aktualizujeme na štítek odpovídající tomuto dílu seriálu.

$ hg pull
$ hg up "2. díl"

Případně si je můžete stáhnout jako bzip2 archiv přes web.

Struktura adresářů

S Netbeans jste asi už pracovali, takže jen pro zopakování – adresář projektu obsahuje tyto podadresáře: build (zkompilované třídy), dist (archiv připravený k distribuci – v našem případě .war), nbproject (metadata projektu), src (zdrojové kódy v Javě), test (zdrojové kódy testů), web (JSP a WEB-INF a konfigurace webu). V IDE vypadá pohled na složky trochu jinak (klasický pohled na adresáře najdete v kartě „Files“).

Java II

V adresářích build a dist asi zatím nic nemáte, protože přeložené třídy a balíčky do Mercurialu nedávám. Aplikaci si zkompilujeme v IDE a ve složce dist se nám objeví distribuční balíček nekurak.net-web.war. Což je vlastně normální ZIP archiv. Obsahuje jak JSP stránky, tak důležitou složku WEB-INF, zkompilované třídy, případné knihovny a všechny konfigurační soubory naší aplikace. V ideálním případě je .war archiv všechno, co potřebujete ke zprovoznění aplikace na aplikačním serveru.

Základní stavební kameny

Svět enterprise Javy je velice rozmanitý a bohatý na technologie. Pro začátek nám ale bude stačit, když se seznámíme s těmito pojmy.

  • Servlet – javovská třída, potomek javax.servlet.http.HttpServlet. Stará se o vyřizování HTTP požadavků (metody doGet(), doPost() atd.). Servlet je namapovaný na určitou cestu v URL, např. /upload . Můžete ho použít v roli controlleru nebo třeba pro nízkoúrovňové věci typu upload/download souborů (pracujete přímo s vstupním a výstupním proudem, máte absolutní kontrolu nad vyřizovaným HTTP požadavkem).
  • JSP – Java Server Pages – dokument založený na XML. Zatím si ho můžete představit jako šablonovací systém. Při nasazení na server se JSP překládají do jazyka Java a následně se kompilují – vznikne z nich normální servlet. JSP nemusíme používat jen pro vytváření HTML či XHTML stránek, můžeme z nich generovat třeba SVG nebo RSS/Atom, jakýkoli XML formát a konec konců i prostý text.
  • Filtr – mezi zdrojem obsahu (JSP, servlet) a klientem může být řetězec filtrů – něco jako unixové roury, skrz které prochází proud dat. Filtry mají různé využití (transformace dat, autorizace, komprese…), jednou jsem psal např. filtr, který ze stránek odstraňoval háčky a čárky, aby se stránky daly prohlížet i v „hloupých“ zařízeních. Filtry v naší aplikaci zatím nebudeme potřebovat.
  • JavaBean – celkem běžná třída (viz dále), která se používá jako prostředník mezi JSP (v jazyce XML) a logikou aplikace (v jazyce Java).
  • EJB – Enterprise JavaBean – komponenta běžící na serveru, která poskytuje určitou službu (implementuje rozhraní), vhodná pro budování modulární architektury. EJB zapouzdřují byznys logiku aplikace a je možné k nim přistupovat i přes síť – např. pomocí protokolu CORBA/IIOP. V naší aplikaci EJB použijeme, ale spíše pro ukázku – webové aplikace v Javě lze úspěšně vytvářet i bez EJB.

Je sice možné psát celý web jen v jazyce Java (použijeme jen servlety) nebo jen v JSP („obohatíme“ je skriptlety), ale není to moc šťastné ani obvyklé řešení. Jistě mi dáte za pravdu, že vytvářet dokument, (X)HTML stránku, je daleko příjemnější v nějakém „dokumentovém“ jazyce (tedy JSP – XML), zatímco programovat se nám bude lépe v jazyce Java. „Programovat“ dokument v programovacím jazyce nebo naopak psát program v jazyce značkovacím není zrovna elegantní.

Využívejme proto možností Javy a těchto dvou jazyků. Java nás přímo vybízí, abychom své aplikaci dali vrstvenou architekturu. Prezentační logika patří do JSP a aplikační logika patří do javových tříd.

Nasazení aplikace na server

Pokud jste byli z PHP zvyklí upravovat skripty přímo na serveru, raději na to zapomeňte. Tento způsob práce je sice možný i v Javě (jedná se o tzv. „hot deploy“ kdy si aplikační server hlídá změny souborů v určitém adresáři), ale bude lepší se chovat trochu „spořádaněji“. Nasazení (nahrání) aplikace na aplikační server se nazývá „deploy“. Ten se dělá buď v nakopírováním .war souboru do příslušného adresáře, nebo použitím HTTP nebo CLI API – záleží na zvoleném aplikačním serveru.

Předejdete tak trapným situacím, kdy po upgradu aplikace záhadně „zmizí“ některé její funkce nebo opravy chyb a nakonec se ukáže, že nějaký váš kolega upravoval aplikaci přímo na serveru a „zapomněl“ dát upravené zdrojáky do verzovacího systému. Pokud chcete mít jistotu, nekompilujte aplikaci na vývojářském desktopu, ale na jiném počítači, na kterém neprobíhá vývoj – pouze se tam stahují zdrojové kódy z verzovacího systému –  takto vytvořené .war archivy nejdříve nasadíte na testovací server a potom na ostrý.

Nasazení aplikace na server můžeme v případě Glassfishe provést z příkazové řádky. Program asadmin se nachází v adresáři bin v instalaci vašeho Glassfishe.

$ asadmin deploy nekurak.net-web.war
Enter admin password for user "admin">
Application deployed successfully with name nekurak.net-web.
Command deploy executed successfully.

Výchozí heslo je prázdné, takže stačí odentrovat. Soubor nekurak.net-web.war obsahující zkompilovanou aplikaci naleznete v adresáři dist v netbeansovém projektu.

Daleko pohodlnější je provádět deploy přímo z IDE. Pokud jste si stáhli Netbeans ve verzi All nebo Java, měli byste mít už vše nastavené.

Java II

Nasadit aplikaci na server pak můžeme jednoduše spuštěním projektu. Možná bude jen potřeba vybrat aplikační server ve vlastnostech projektu – na stejném místě se nachází volba „Deploy on save“ – při uložení JSP nebo jiných zdrojáků se aplikace okamžitě nasadí – velmi užitečné pro ladění.

Tímto způsobem lze pracovat i se vzdálenými servery (používá se HTTP API). Další možností jak dostat naši aplikaci na server je webové administrační rozhraní (port 4848).

Základy JSP

Naši aplikaci začneme stavět trochu „od střechy“ – místo datového modelování a psaní javových tříd se podíváme na JSP (prezentační vrstvu). Možná vám to přijde nezvyklé, ale tenhle postup má něco do sebe a můžete se s ním setkat i v agilních metodikách jako je Getting Real (Designujte rozhraní předtím, než se začne programovat).

Když se podíváte na index.jsp, vidíte XML dokument. Až na hlavičky je to v podstatě obyčejná HTML stránka, do které jsou „sem tam“ vložené JSP značky, které obstarávají aktivní obsah. Toto XML využívá jmenné prostory, zatímco HTML značky jsou v něm „jen tak“, JSP značky začínají jsp:. Abyste tyto značky mohli používat, musíte si jmenný prostor přidat do elementu <jsp:root/>  – příklad:

<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
      xmlns:c="http://java.sun.com/jsp/jstl/core"
      version="2.0">

Tím jsme si do dokumentu přidali dva jmenné prostory. Jak si je pojmenujete, je na vás, nicméně je zvykem používat jsp (základ JSP stránek), c (značky pro větvení, cykly atd.), fn (funkce), fmt (formátování). Kromě těchto standardních knihoven značek si můžete vytvářet i své vlastní a vlastní jmenné prostory (o tom v některém z příštích dílů).

Vkládání stránek

Začneme něčím jednoduchým – dejme tomu, že chceme mít v zápatí každé stránky informaci o copyrightu a licenci. Obsah jiného souboru vložíme pomocí direktivy  include:

<jsp:include page="WEB-INF/casti/paticka.jsp"/>

Vkládat můžeme stránky z libovolného adresáře naší aplikace, nicméně pokud se jedná o (pod)stránky, které budou pouze vkládány a uživatel by k nim přistupovat přímo neměl, je dobré je umístit do nějakého podadresáře ve WEB-INF  – jeho obsah není přes HTTP přímo dostupný.

Při vkládání můžeme předávat parametry a pak se na ně ve vkládané stránce odkazovat – viz index.jsp a paticka.jsp. V tomhle případě je to poněkud samoúčelné, ale je dobré o této možnosti vědět.

Skriptlety

Jak jsme si řekli výše, z JSP stránky nakonec stejně vznikne servlet. Tak vás možná napadne, že by se do tohoto procesu někdy hodilo vstoupit a trochu si ten Java kód vygenerovaný z JSP poupravit. Možné to je a slouží k tomu tzv. skriptlety. Skriptlet je kousek Java kódu uzavřený do příslušných JSP značek – příklad:

<jsp:scriptlet>
    out.println("No nazdar! &lt;br/&gt;");
    out.println("Právě je: " + new java.util.Date());
</jsp:scriptlet>

V proměnné out máme zpřístupněný výstupní proud, který vede ke klientovi. K dispozici jsou i další proměnné ( request, session atd.), po stisknutí Ctrl+mezerník vám Netbeans budou napovídat i metody použitelné na těchto objektech.

Kdo ví, proč jsme museli <br/> zapsat jako entity, má bod.

Po tom, co jsme se skriptlety naučili používat, je zase rychle zapomeneme – skriptlety totiž vedou k nepřehlednému a chybovému kódu. Pokud budete cítit potřebu skriptlet použít, je dobré se zastavit a zamyslet – s velkou pravděpodobností totiž děláte něco špatně. Dost možná se vám začala prolínat prezentační a aplikační logika a programujete v prezentační vrstvě. Programování a logika aplikace patří do javovských tříd, zatímco v JSP se už staráte jen o prezentaci – přebalíte objekty do (X)HTML značek, naformátujete a pošlete uživateli. Přesto jsou v některých případech skriptlety přípustné – např. když se rozhodnete napsat controller pomocí JSP místo servletu… Ale nikdy by neměly tvořit běžnou součást vašeho programu.

Podmínky – if, else

I v prezentační vrstvě je potřeba nějaké to větvení. Slouží k němu JSTL značky ze jmenného prostoru http://java.sun.com/jsp/jstl/core, který se typicky zkracuje c. Jednoduchý podmíněný blok vypadá takhle:

<c:if test="${param.akce == 'informace'}">
    <p>Vypíšeme nějaké informace.</p>
</c:if>

Odstavec se vypíše, pokud GET/POST parametr akce je „informace“.

Do ${…} zapisujeme tzv. expression language a param zde představuje pole, které obsahuje parametry stránky – buď GET/POST z HTTP požadavku nebo parametry předané jinou JSP stránkou – viz „vkládání stránek“ výše.

Pro složitější větvení if, else if… else, použijeme značku <c:choose/> viz soubor  index.jsp.

Použití JavaBean v JSP

Abychom měli v JSP co prezentovat, potřebujeme nějaká data. Ta vezmeme např. v databázi, v souborech nebo z nějakého jiného zdroje (webová služba, EJB…) a do JSP je dostaneme pomocí tzv. JavaBean, což jsou celkem obyčejné třídy s gettery  a settery. Jejich specifikace má sice přes sto stránek, ale v podstatě stačí vědět, že:

  • beana by měla být serializovatelná,
  • mít bezparametrický konstruktor
  • zpřístupňovat svoje proměnné pomocí getterůsetterů

V rámci JSP stránky si potom stačí vytvořit její instanci:

<jsp:useBean
 id="podnikyWeb"
 class="cz.frantovo.nekurak.web.PodnikyWeb"
 scope="request"
/>

Hodnota atributu id je název proměnné pod kterou instance bude přístupná v JSP, class je název instanciované třídy (JavaBeany) a scope je rozsah platnosti. Vytvořený objekt (beana) může být platný v rámci daného HTTP požadavku ( request) nebo uživatelské relace ( session), další možnosti jsou page a application. Pokud direktivu useBean použijete pro stejné id a rozsah víckrát, nic se neděje – použije se již existující instance. Přesný postup naleznete v online nápovědě:

Java II

Použití JavaBeany je snadné. Třída PodnikyWeb má metodu getPodniky(), která vrací seznam podniků. Zatím nemáme žádnou databázi, takže jsou jejich názvy zapsané přímo ve zdrojovém kódu, ale to pro tuto chvíli nevadí. Podniky si vypíšeme např. jako nečíslovaný seznam:

<ul>
    <c:forEach var="p" items="${podnikyWeb.podniky}">
        <li>${p.nazev}</li>
    </c:forEach>
</ul>

Všimněte si, že se v JSP neodkazujeme na metodu getPodniky(), ale na vlastnost podniky (přestože se nakonec metoda getPodniky() zavolá).

Ošetření výstupu, escapování

Při psaní webovým aplikací je velice důležité ošetření vstupů – nikdy nevíme, co se nám zlomyslný uživatel pokusí podstrčit. Někdy mám pocit, že se tohle téma přeceňuje a místo aby lidi hodnotili webovou aplikaci jako takovou, zkoušejí jako první věc, jestli jsou „schopnější“ než její autor a jestli nezapomněl něco ošetřit. Na druhou stranu případy různých SQL injekcí a jiných chyb tu jsou pomalu každý den, takže na tom asi něco bude.

Ale nejde jen o vstupy z formulářů. Na co si dát pozor:

  • Vstup od uživatele – převážně z formulářů. Tyto vstupy většinou přímo nevypisujeme, ale pokud ano, musíme je escapovat, aby nám nerozbořily naši (X)HTML stránku. Viz příklad níže.
  • SQL dotazy – základní pravidlo zní: nelepit SQL z kousků textu, ale používat parametrizované dotazy. Více v příští kapitole, kde se SQL databázím budeme věnovat.
  • Výstup dat z databáze nebo odjinud – možná to zní paranoidně, ale věřit bychom neměli ani svým datům. Pokud na výstupu z databáze nečekáme HTML, měli bychom ho před vypsáním stejně prohnat escapovací funkcí (i když se domníváme, že např. v daném sloupečku žádné nebezpečné znaky nejsou). Odpustit si to můžeme tak leda při vypisování číselných hodnot – např. do datového typu int opravdu nejde nacpat nic, co by nám (X)HTML narušilo. Pokud je HTML přípustné (např. formátovaný text článku), musíme mít buď jistotu, že se do databáze (nebo třeba do souborů) žádné závadné značky nedostanou, nebo text vždy před výstupem prohnat XML validátorem a zkontrolovat, že obsahuje jen povolené značky a atributy (což ale může aplikaci trochu brzdit).

Pro ošetření výstupu do HTML (nebo obecně XML) použijeme následující značku:

<p><c:out value="${param.parametr1}"/></p>

Někdy ale potřebujeme text umístit do atributu (např. title), tam ale výše uvedenou značku nedostaneme. V takovém případě použijeme funkci:

<abbr title="${fn:escapeXml(param.parametr1)}">„escapovaný“</abbr>

Teď můžeme klidně do formuláře zadávat závorky a uvozovky jaké chceme a (X)HTML výstup zůstane nenarušený. Tyto příklady naleznete v souboru  escapovani.jsp.

Osobně doporučuji ošetřovat text co nejpozději – těsně před tím, než by nám mohl uškodit – např. před vypsáním do (X)HTML. Naopak postup, kdy se všechny vstupy ošetří hned jak přijdou z formuláře, je dost nešťastný. Jednak může dojít k několikanásobnému escapování (jistě jste už někdy viděli HTML entity na výstupu, kde neměly co dělat). Jednak nevíme, proti čemu text ošetřujeme – jestli proti narušení HTML/XML (ostré závorky, uvozovky…) nebo proti SQL injekci (apostrofy), takže se pak stává, že escapujeme něco, co nemáme. A jednak nevíme, co se s daty stane potom – např. je ošetříme příliš brzo, uložíme do databáze, jenže tam je někdo ručně upravuje a přidá do nich nebezpečné znaky.

Kódování ve formulářích

Doposud jsme s kódováním znaků neměli problém, vše jsme měli v UTF-8, jak bezstarostný život… Až na jeden detail: při odeslání formuláře si na serveru načteme GET (nebo POST) parametr, chceme ho zobrazit a vidíme něco jako:

ÄžšÅáýÞéýáÃ

Jako výchozí se v tomto případě totiž použije kódování ISO-8859-1. Tato situace se často řeší následujícím skriptletem:

<jsp:scriptlet>
    request.setCharacterEncoding("UTF-8");
</jsp:scriptlet>

Ale jak jsme si již dříve řekli, skriptlety jsou fuj. Výchozí kódování si nastavíme v souboru  sun-web.xml:

<parameter-encoding default-charset="UTF-8" />

Pokud to nechceme nebo nemůžeme udělat (např. máme jiný aplikační server), ani tak se nemusíme uchylovat ke skriptletům. Použijeme značku ze jmenného prostoru  http://java.sun.com/jsp/jstl/fmt:

<fmt:requestEncoding value="UTF-8" />

Více si můžete přečíst v odkazech na konci článku (tento problém lze řešit i filtrem).

Soubor web.xml

Tento soubor obsahuje konfiguraci naší webové aplikace. Pomocí značky <welcome-file-list/> se v něm nastavuje výchozí stránka adresáře – typicky index.jsp, index.html  – tedy obdoba direktivy DirectoryIndex v Apachi. Dále se tu např. definují servlety a filtry a jejich mapování na URL nebo třeba chybové stránky. Tento konfigurační soubor je XML, takže vám ho IDE validuje už během editace a hned se dozvíte, pokud tam máte nějakou syntaktickou chybu. Také vám nabízí konfigurační volby i s dokumentací, takže většinou není potřeba hledat nikde v manuálech. V Netbeans můžete většinu voleb web.xml zadat i přes GUI, přesto je dobré se alespoň na závěr podívat na „surový“ konfigurační soubor.

Chybové stránky

Když se uživateli zobrazí standardní chybová stránka aplikačního serveru, vypadá to jednak neprofesionálně a jednak to může znamenat jisté bezpečnostní riziko (z výpisu chyby se útočník dozví informace, které by vědět nemusel). Proto je dobré si definovat vlastní chybové stránky – to se dělá pomocí značek <error-page/>. Ve web.xml si nastavíme:

<error-page>
    <error-code>404</error-code>
    <location>/WEB-INF/chyby/404.jsp</location>
</error-page>

Nejčastějšími chybami jsou 404 (stránka nenalezena) a 500 (interní chyba serveru). Chybové stránky můžou být definované nejen na základě HTTP kódů, ale i na základě výjimek jazyka Java (viz soubor web.xml). Např. při SQL výjimce můžeme uživateli říct, že došlo k chybě při práci s databází (pokud mu takovou informaci chceme sdělovat).

Chybová stránka může být i JSP, ovšem pokud v ní uděláme chybu, zobrazí se místo ní ta standardní „pětistovková“. Takže raději opatrně – často si vystačíme s chybovými stránkami v prostém (X)HTML.

Závěr

Dnes jsme se seznámili se základními částmi, ze kterých se webová aplikace skládá, a vytvořili svoje první JSP. Měli bychom být (částečně) odolní vůči záškodníkům a neděsit normální uživatele standardními (ošklivými) chybovými hláškami. Příště se budeme věnovat lokalizaci aplikace a práci s relační databází.

Odkazy

Komentáře

Subscribe
Upozornit na
guest
35 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Honza Marek

Díky za článek. Jen co se týče formy, příště bych omezil použití tagů abbr s vyskakovacím title. Blbě se to čte.

Miki

Naopak, mě to text oživuje…

v6ak

Jo, pokud máš prohlížeč, který to podporuje. Já bych na to pro Operu mini potřeboval nějaký šílený bookmarklet.

avatar

Yet another useful article …

b*d

Po předcházejícím článku jsem se pustil po prozkoumávání ostatních technologií. Našel jsem video, kde člověk píše všechny xml atp. pro JavuEE v emacsu (a že píše rychle). V Netbeans nebo Eclipse takové problémy až tak viditelné nejsou. A pochvaloval si Plone/Zope.
Je to už starší video (odkaz na stránkách plone.org). Po prozkoumání:
mají ear/war říkají tomu egg. Egg se může taky psát ručně, ale většinou se generuje. Mají viewlety, templaty, etc. kromě toho že obohacují tagy vlastními attributy proti samostatným v jsp je to hodně podobné.
Pro mně z toho vyplynulo, že Plone/Zope se přibližuje Javě a Java Zope.
Rails, TurboGrears, atp. bylo jaksi mezi těmito světy.
Asi není náhodou, že Python a Java jsou asi nejoblíbenější u Googlu.

Python má výhodu, že netáhne s sebou břemeno C/C++. Ale jako programátor v C++ musím příci, že mnoho věcí to se považuje za hype se ve větších týmech zakáže. Ono je totiž sranda napsat jednu web-aplikaci s pár stránka v málo lidech. Pokud to má aplikace mít life-cycle delší (i několik let) tak ukecanost a restrikce Javy se poměrně hodí.

I když „properties“ z Pythonu by byly skvělé. Už jenom proto, že psát triviální inline getry/setry je opravdu vopruz a alespoň má člověk možnost dostat se ke getru při dědění, pokud ho autor „zapoměl“. Bezpečnost tu nemá smysl, může vracet kopii (data jsou má).

pr.rybar

V Jave mi tiez chyba referencia na metodu a analog dekoratoru v pythone.

Vyborne zhrnutie tvorby web aplikacii je
http://oodt.jpl.nasa.gov/…-web-app.mov

b*d

No pravě že „už“ moc ne. Java a frameworky už jsou na úrovni Python a programovaní je už skoro myší.

To porovnání by lepší pokud by tam dal Zope vs Java EE app server.

Je jasné, že Emacs není IDE na úrovni Eclipse. Já jsem nenapsal SQL ani xml (web.xml atp.) už dlouhou dobu. Všechno zařídí IDE. Další věc je, že jsem ho neviděl udělat ani jeden test!

b*d

Reference se nepoužívají. Já jsem vůbec rád, že tyhle věci v Javě nejsou. Problém je s lidmi bez praxe. Asi si dokážete živě představit, jak by jejich commit vypadal.

Dekorátor – to samozřejmě je (třeba ve Springu se používá velmi hodně – deklarativní bezpečnost, transakce atd.). Např. vyhodím-li RuntimeException provede se rollback i na session.

Ale na druhou stranu, přemýšlím že pro start-up low/medium scale projekty začnu využívat více Plone. Teď jenom přijít na to, jak ho skinovat.

pr.rybar

Zasa sa asi nerozumieme :)

> Reference se nepoužívají. Já jsem vůbec rád, že tyhle věci v Javě nejsou. Problém je s lidmi bez praxe. Asi si dokážete živě představit, jak by jejich commit vypadal.

Myslel som to, comu sa v c# hovori delegat.

> Dekorátor – to samozřejmě je (třeba ve Springu se používá velmi hodně – deklarativní bezpečnost, transakce atd.). Např. vyhodím-li RuntimeException provede se rollback i na session.

Java ako jazyk NEMA obdobu dekoratora v Pythone, nieco ako wrapper nad metodou.

ahl

Jenomže v javě nic takového jako samostatná metoda neexistuje. Reference na metodu je tedy nesmysl, protože když chci volat metodu a nevím jakému objektu/třídě patří, tak se může dít skoro cokoliv(metoda může měnit atributy toho objektu/třídy). Reference na metodu se v javě implementuje jako rozhraní s jednou definovanou funkcí. Z toho důvodu se mi nelíbí ani ty delegáty v c#.

pr.rybar

> Jenomže v javě nic takového jako samostatná metoda neexistuje.

Nevidim dovod na to aby som nemohol vediet referencovat metodu danej triedy (a zvlast staticku).

Velmi sa mi paci signal-slot v jazykoch QT, gtkmm, Python, Vala, …
Ale v Jave je to skrabanie sa cez hlavu (vela kodu pre malickost). Je to skratka Java. :(

alef0

Delegáty nie sú, hej, rieši sa to cez implementáciu interfejsu, prípadne anonymné vnútorné triedy. Potom to v takom v Swingu to vyzerá dosť masakrálne.

Počkajte na Javu 7, budú closures, už je to schválené.

jondy

Dekoratory v Jave samozrejme existuji … rika se tomu AOP :-). Delaji se s tim presne ty same veci

pr.rybar

Skutocne viete co je dekorator v jazyku Python a ste si isty, ze to iste je v jazyku Java? :)

AOP je programovacia paradigma a Python dekorator je prvok jazyka.
Neplette si prosim pomarance s hruskami.

Priklad pre lepsie pochopenie:
To ze mozem jazdit na bicykli aj na koni este neznamena, ze kon je bicykel a naopak. :))
Jazdit na koni je nieco ine ako jazdit na bicykli, verte mi. :)

Anonymní

Ale ucel se dostat z bodu A do bodu B bude stale stejny…

pr.rybar

Ale mne ide o ten vyrazovy prostriedok, nie len o ucel. :)

Nie je mi totiz jedno ako sa dostanem z Bratislavy do Prahy (alebo naopak). Vlakom ci na bicykli? To mi skutocne jedno nie je. :(

*) Naucme sa vyjadrovat presne. Naucme sa chapat vety, tak ako ich autor napisal. Nie iba kazde druhe solovo.

xtr

Ja teda nevim, dekorator – aspon pokud myslite ten navrhovy vzor – se da realizovat v jave a klidne i v javascriptu, nebo ne?

b*d

Tak po dvou dnech s Plone/Zope/Python končím. Ony legendární vlastnosti, s tím jak se požadavky posunují od konkrétního k obecnému, zanikli. Je to vlastně už jako v Javě. Akorát jde o ten směr vývoje: Konkrétní->Obecné Python
Obecné Java

Dokumentace je k =censored= Next skáče na další kapitolu a né sekci, takže se to ani nedá číst.

Celkově mám dojem, že té komunitě chybí směr a cíl. Na jedné straně je snaha nebýt bloated JavaEE, na druhé nabídnout dostatečnou obecnost. Jenže tam naráží Konvence oproti Konfiguraci.

Ve zmíněném videu je totož vynecháno, že část IDE je vlastně zahrnuta v app serveru / Plone. Takže se něco dělá tady, něco tam…

Btw. v soutěži o jednoduchý publikační systém vyhrál WordPress a co se týče dalšího mid sized, tak se bude psát v Jetty₊Hiber­nate+Spring(Web­flow, JPA, IceFaces). Je to rychlejší v tom, že se to dá na 90% naklikat v dobrém IDE (MyEclipseIDE v kombinaci s MDA toolem).

dm

Zájemcům o webové programování v Javě doporučuji prohlédnout projekt
http://www.playframework.org . Je to odlišný přístup, než jsou klasické ‚servlet based‘ javovské frameworky, hodně inspirováno systémy je např. Django . A je vidět, že to vyvíjí někdo, kdo to taky sám používá :-)

David

v6ak

Hmm, pěkný, ale Groovy jako jazyk pro šablony asi bude znamenat nemalý slowdown, možná třeba Scala by byla vhodnější. Platforma Java prostě nebyla určena pro dynamicky typované jazyky. A hlavně, pro komfort programátora je důležité, že tím ztrácí statickou typovou kontrolu.

xtr

Play framework je jiste krok zajimavym smerem, treba pro mensi dynamicke weby. Ad rychlost groovy v sablonach – urcite i v Play existuje moznost zkompilovanou sablonu dat do kese ; jinak, nemylim-li se, Django dnes uz spustite pod Jython 2.5 , chcete-li ho provozovat nad JVM.

v6ak

No dokonce bych se i divil, kdyby ten bytecode nebyl cacheován. Pro dobrý výkon je důležité nejen cacheovat bytecode, ale i v paměti načtené třídy (verifikace bytecode, optimalizace jako třeba inlineování virtuálních metod, JIT cache apod.).

Jenže u dynamicky typovaného jazyka se řádově hůře optimalizuje. Virtuální metody ve staticky typovaných jazycích bývají v Javě volány přes invokevirtual. Jak jsou volány metody u dynamicky typovaných jazyků? Nevím, ale nabízí se mi tu dvě možnosti:
* Reflection, IMHO celkem slowdown
* invokedynamic (mám pocit, že přibude v Javě 7)
V obou případech jsou optimalizace zřejmě mnohem složitější.
Navíc se podívej na různé benchmarky: http://www.google.cz/search?q=java+groovy+preformance&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:cs:official&client=firefox-a

Michal Augustýn

Super článek!

Docela bych uvítal nějaký slovníček pro ASP.NET vývojáře (jako jsem já), protože mám pocit, že tu existuje mapování téměř 1:1. Rovnou můžu začít (v Javě jsem web nikdy nedělal, takže to je jen nástřel a klidně mě opravte):

  • Servlet = HTTP Handler
  • JSP = ASPX
  • Filtr = HTTP Module
  • JavaBean = POCO splňující určité konvence, instance obhospodařované nějakým kontejnerem
  • <jsp:scriptlet> == <script runat=„server“>
  • web.xml = web.config
jondy

Trochu vysvětlení:

  • Servlet = HTTPHandler ± OK
  • JSP = ASPX už pokulhává. ASP.NET je hlavně komponentová technologie. JSP je hlavně šablonovací technologie. JSP vám nedefinuje ani nemapuje žádné komponentní třídy na pozadí. Spíš JSP = staré ASP :-)
  • Filtr = HTTP Module ± OK
  • JavaBean (označované také jako POJO) = POCO sedí
  • <jsp:scriptlet> == <script runat=„server“> ± OK:
    V ASP.NETu uvnitř scripletu definujete tělo třídy která vzniká překladem ASPX souboru (tedy metody a property třídy výsledné stránky). Kdy se co volá je pak dáno lifecyklem (děsný slovo) třídy Page od které výsledná třída stránky dědí.
    JSP soubor se přeloží – vytvoří pouze jednu metodu výsledné třídy a tedy scriplet se vkládá právě do toho místa výsledné metody kde je uvedený. Umístění scripletu v JSP definuje kdy se jeho kód volá (častý zdroj mučivých nocí JSP začátečníků :-D).
  • web.xml = web.config sedí
smilelover

Kdyz uz, tak spis JSF ~ ASPX…

b*d

A jsf tady máme proto, aby jsme mohli používat IceFaces (icefaces.org)

Michal Augustýn

Díky za upřesnění a doplnění.

Btw. ASP.NET není komponentová technologie (tedy pokud neuvažujeme pouze o Handlerech a Modulech, příp. Providerech). Pravděpodobně jsi měl na mysli ASP.NET WebForms. Ono je důležité se hlavně teď vyjadřovat přesně, protože tu máme ještě moje oblíbené ASP.NET MVC.
Právě v ASP.NET MVC jsou ASPX stránky degradovány na úroveň šablon. To byl ten motiv, proč jsem napsal JSP = ASPX.

Pokud se orientuješ v Javovském prostředí, jaké jsou protějšky ASP.NET MVC (Spring?) a ASP.NET WebForms?

Jakub D.

ASP.NET MVC = Treba Struts nebo Spring MVC
ASP.NET WebForms = JSF

Asi nejvetsi rozdil mezi .NET a Javou je v tom, ze vam nikdo nerika, jaky framework nebo databazi mate pouzit. Kdysi jsem cetl knizku o tvrobe webu pomoci .NET 1.1 a trochu me vydesilo treba to, jak se lisila uroven podpory databazi pro MS SQL Server a ty ostatni. Treba pojmenovane parametry SQL dotazu byly podporovany jen pro MS SQL a rozdil vykonu dle autoru pry cinil 20%, coz mi prisel vendor-lockin jako prase.

K vasi otazce – V Jave si muzete vybrat z mnoha technologii pro generovani frontendu a ty muzete dale doplnit dalsimi knihovnami pro generovani konkretnich prvku HTML. Treba standard JSF ma implementace od Sunu (Mojara) i Apache (MyFaces) a obe muzete doplnit temito velkymi knihovnami: http://www.jsfmatrix.net/, plus tuny dalsich – mensich. Nutno dodat, ze na JSF se muzete uplne vykaslat a pouzit treba Struts, Spring MVC, Wicket nebo Tapestry. Prave tohle je opravdova sila Javy – naprosta svoboda, naprogramujte si to, v cem chcete :-))

JSP bych snad ani nezminoval, to je mrtva technologie, nahrazena Facelety, jez jsou nyni primo soucasti standardu JEE 6. Nekde v diskusi zaznelo, ze JSP jsou pro sablonovani, coz je blbost, protoze sablonovani v JSP je spise parodie, vykonove je to take bida.

tom

Ano,
To je typický argument pro Javu. Máme takový a makový framework pak můžete použít ještě ten čtvrtý a pátý. A když to všechno dohromady zkombinujete tak to bude fakt super. On pak vznikne takový špagetový propletenec ve kterém se vyzná akorát autor aplikace.

Každý z těchto frameworků má životnost cca 2–4 roky. Pak přestává být podporovaný a nastupuje jiný framework. Málokdo si však uvědomuje že velké aplikace mají životnost daleko delší. Přejít na nový framework u těchto aplkací nelze protože neexistuje zpětná kompatibilita.
ASP .NET kontinuálně rozvíjí svojí funkcionalitu. Přidává nové komponenty a funkcionality ale hlavně je to všechno kompatibilní.
Nemusíte se učit framework za frameworkem. Prostě se naučíte ASP .NET. Když přijde nová verze tak projekt otevřete pouze v novém prostředí a pod novou verzí. To je TO ZA CO SE PLATÍ. A teď nemluvím o webu o 10–20 stránkách.

Co se musím naučit v Javě když chci programovat web na nějaké profi úrovni:

Vývojové prostředí (Netbeans například)
Aplikační server (GlassFish například)
Java Server Pages
Servlety (do těch se to kompiluje takže znalost by měla být)
Java Server Faces
Icefaces
Struts
Spring
Facelety

Co se musím naučit v .NET když chci programovat web na nějaké profi úrovni:

Vývojové prostředí Visual Studio
ASP .NET + IIS Server
ASP.NET MVC (možná, já ho nikdy nepoužil)

jondy

No plne ekvivalentni technologie jako takove asi neexistuji. Spis nektere frameworky jsou postavene na podobne filosofii, ale dost se lisi pristupem.

Napr JSF je puvodne klasicka MVC technologie, ale pomoci ruznych dalsich frameworku se pouziva typicky jako komponentova (protoze JSF je soucast JEE specifikace ktera je koncipovana jako komponentova). Z toho u predchozich verzi vznikalo hodne averze vuci JSF protoze takovyhle ohnuti se podepisovalo na vykonu a kompikovanosti programovani. Aktualni verze JSF + JSP uz tohle resi, ale je moc brzo hodnotit jak dobre :-)

Ono vubec mi prijde ze nejaky striktni deleni MVC, MVP a komponentove frameworky je hodne umele. V predchozim zamestnani jsme napriklad jeli MVC i ve starem APS.NETu 2.0. Jednoduse jsme ignorovali cast toho co MS do .NETu cpe, napsali par knihoven a byla to klasicka ukazka MVC (odesel jsem akorat, kdyz se zacalo pro model vrstvu integrovat NHibernate).

Me osobne nejvic vyhovuje Apache Wicket jako komponentova technologie. Hodne lidi kteri programovali v ASP.NET WebForms presli prave na Wicket, protoze ma podobne principy skladani a programovani komponent. Na druhou stranu Wicket se da pouzit jako klasicky MVC framework :-). Je navrzeny tak, ze AJAX a REST aplikace se v nem tvori uplne prirozene.

Mozna srovnani s .NETem jako takovym je Spring. Resi priblizne stejny rozsah funkcionality (vcetne webovych aplikaci), ale hodne se lisi pristupem. .NET ma tradicnejsi imperativni pristup (ne striktne ale spis principialne) a Spring spis jde deklarativnim pristupem (dependecy injection, AOP, COC)

mich

JavaBean se neoznačují POJO.

http://en.wikipedia.org/…_Java_Object

fastcoretux

Tož pěkný článek, už se těším na pokračování ;]

v6ak

Pokud nastane nějaká přípustná chyba (= se kterou bylo počítáno) způsobená uživatelem, třeba 404, pak ji co nejlépe popsat.
Pokud nastane vnitřní chyba, pak:
Jsem-li ve vývojovém prostředí, pak klidně popsat pokud možno co nejlépe.
Jsem-li v produkčním prostředí, pak se slušně omluvit a popsat co nejobecněji. Uživatele přece nezajímá, co se stalo. Tomu stačí, že to nefunguje a že on za to nemůže. Jestli je problém s databází nebo nastal NullPointerEx­ception může být uživateli úplně fuk. Komu to naopak fuk být nemusí je útočník.
Tolik k mému přístupu.

YF

Vito – chvalim te za tvuj pristup – jen tak dal! Takovy utocnik kdyz dostane do ruky takovou NPE – tak pak nastava skutecne peklo!

v6ak

Tak konkrétně NPE bez stacktrace je zpravidla na nic. (BTW: už jsem viděl blíže nespoecifikovanou banku jak ukázala něco podobného i se stacktrace :D)

Ale třeba info o problému s DB může inspirovat náhodného kolemjdoucího po zadání apostrofu k SQL injekci. A to si necucám jen tak z prstu.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.