Znáte zprasenější (J2EE) zdroják? (diskuse)

[Salamek]

Asi udělám zápisek nejsrasenější PHP kod všech dob aneb upečme 2TFLOP cluster jedním SQL dotazem , boužel myslím že by se to majitelovi kodu nelíbilo a poslal by na mě fízly I když přemýšlím že by to za tu srandu i stálo nebudu uvádět o co se jedná .. jen napovím že to je webovka stále v provozu s cca 20k hráči

[Mrkva]

Webgame? :) Ale myslim, ze zverejnit jeden SQL dotaz (pokud navic upravite nazvy sloupcu) rozhodne nemuze byt duvod k trestnimu stihani :) IANAL!

[Salamek]

nee webgame to není tak ok pro zasmátí uvedu pár příkaldů Počkejte projdu to cele a vytáhnu perličky

[Salamek]

//pravděpodobně kontrola prihlasování do adminsekce "login" je jemno administratora, to samné je tam i na IP a hesla
if( ($zaznam1[admin]!=1 or $zaznam1[admin]!=2 or $zaznam1[admin]!=3 or $zaznam1[admin]!=4) and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and 
$zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and $zaznam1[jmeno]!='login' and 
$zaznam1[jmeno] != 'login' AND $zaznam1[jmeno]!='login' AND $zaznam1[jmeno]!='login' AND $zaznam1[jmeno]!='login'){echo "Nejste admin proto nemáte přístup k admin rozhraní.";exit;};


//menčí insert
MySQL_Query("insert into rasy (rasa, nazevrasy, nazev, jed1_nazev, jed1_utok, jed1_obrana, jed1_cena, jed1_lidi, jed4_nazev, jed4_utok,jed4_obrana, jed4_cena, jed4_lidi, jed2_nazev, jed2_utok, jed2_obrana, 
jed2_cena, jed2_lidi, jed3_nazev, jed3_ucinek, jed3_cena, jed3_lidi, jed6_nazev, jed6_ucinek, jed6_cena, jed6_lidi, jed7_nazev, jed7_ucinek, jed7_cena, jed7_lidi, jed8_nazev, jed8_ucinek, jed8_cena, jed8_lidi, 
planeta, vyr_nazev, vyr_vyrob, vyr_lidi, vyr_cena, sdi_nazev, sdi_ucinek, sdi_lidi, sdi_cena, pol_nazev, pol_ucinek, pol_cena, kas_lidi, kas_cena, mes_lidi, mes_cena, mest, lab_lidi, lab_cena, lab_vyz, park_proc,
 park_cena, park_nazev, bra_cena) VALUES ('$rasaci', '$rasanaz', '$rasanazz', '$jed1', '$jed1u', '$jed1o', '$jed1c', '$jed1l', '$jed4', '$jed4u', '$jed4o', '$jed4c', '$jed4l', '$jed2', '$jed2u', '$jed2o', 
'$jed2c', '$jed2l', '$jed3', '$jed3u', '$jed3c', '$jed3l', '$jed6', '$jed6u', '$jed6c', '$jed6l', '$jed7', '$jed7u', '$jed7c', '$jed7l', '$jed8', '$jed8u', '$jed8c', '$jed8l', '$cpc', '$vyn', '$vyv', '$vyl', '$vyc', '$sn', '$sv', '$sl',
 '$sc', '$pon', '$pou', '$poc', '$kl', '$kc', '$ml', '$mc', '$mm', '$ll', '$lc', '$lv', '$pp', '$pc', '$pn', '$bc')");

// if... ne to není vtip
if($x==$y):
echo"BUBUBU";
else:
echo"";
endif;

//typ selectů používaný snad všude ,proč selectovat jen to co potřebujem když můžeme selectnout celou tabulku do pole že ?? 
 $xx = MySQL_Query("SELECT * FROM neco");

		  	$xxx = MySQL_Fetch_Array($xx);

//exituje uživatel ? (do ted tento kód moc nechápu, nedokáži na svém mozku naemulovat dostatečnou úroven debility abych tohle pochopil)

vys2 = MySQL_Query("SELECT jmeno,heslo FROM uzivatele");
			while($hrac2 = MySQL_Fetch_Array($vys2)):
				if($hrac2["jmeno"]==$hracn){$dobre=1;break;};		
			endwhile;
			if($dobre!=1){echo "Neexistující login";exit;};
			$kontrola1 = MySQL_Query("SELECT cislo,jmeno FROM uzivatele where jmeno = '$hracn'");
			do{
				$dobre2=1;
				$kontrola=MySQL_Fetch_Array($kontrola1);
				if($hracn==$kontrola[jmeno]){$dobre2=0;$cislo=$kontrola[cislo];};
			}while($dobre2);

Dobré ne ?

[Luboš Doležel (Doli)]

Vždy o důvod víc, proč si pořídit výkonnější hardware!

[vlastikroot]

Tohle by na DDoS polozilo cokoliv

[kozzi]

Normalni kus kodu. IMHO neni problem v tom dotazu, ale spis v nevykonem HW, a nekvalitni DB. At si poridi Oracle, tam mu takovej insert pojede imho rychleji

[Salamek]

normální co je na tom normálního ? (asi sis nenascroloval dolů jsou tam další příklady ,ten insert se ještě dá to ano , i když by DB šla rozložit mnohem lépe)

[kozzi]

To bylo myšleno ironicky. Já narážel že takto je napsáno hooodně moc kódu. Takže mi to přijde vcelku normální. Tím neříkám správné. Jinak ano ten kód dole je masakr. Místo toho aby si vytahl zaroven heslo jmeno i s cislem, tak vytahne heslo a jmeno. pak vyhleda zaznam znovu stim jmenem, ale ne ze by jen vzal to cislo, on projistotu udela dalsicyklus, kterej stejne projde jen jednou, leda by tam mel cloveka ktery ma stejne jemno vickrat a to by pak bylo nekonzistentni.

[Salamek]

aha tak to jo, ona ta ironie na foru nejde moc poznat , chce to tu jistou ironickou intoanci v hlase a na foru se to lépe identifikuje díky uvozovkám

[kozzi]

JJ. moje chyba. Sem si rikal, ze prece kdyz napisu neco takoveho, tak to nemuze byt mysleno vazne

[Salamek]

no to je fakt, to je zase moje chyba

[Michal Kubeček]

Ona i ta struktura databáze vypadá podezřele a o strkání vstupních hodnot přímo do SQL dotazu ani nemluvím, spousta PHP programátorů si ani nedokáže představit, že by to snad šlo jinak.

[finc]

Vyhodit, nabidnout praci sekretarky. U daneho autora je evidentni, ze rad "hodne pise". Psani ve wordu mu tedy jiste nebude delat problemy :)

[Salamek]

ano to jsem jim říkal taky , ale jejich guru programátoři mě prohlásili za debila a že nic neumím a že oni jsou nejlepší na planetě a kdesi cosi

[Michal Kubeček]

Pokud to poměřují množstvím KB vyprodukovaného zdrojáku… :-)

[xkucf03]

S tím množstvím zdrojáku je to vůbec zajímavé. Ono totiž není množství jako množství – ono je samozřejmě fajn, mít zdrojáků co nejméně, protože pak je to méně práce s jejich udržováním, stačí přečíst méně textu, když hledáme chybu, málo řádků kódu také může znamenat, že jsme se vyvarovali duplicitního kódu (copy&paste). Jenže mi přijde, že někteří programátoři jsou tou minimalizací kódu posedlí a vykládají si to jako „čím méně řádek, tím lépe“. Což pak vede nižší přehlednosti kódu, protože se snaží nahustit co nejvíc věcí na jednu řádku… IMHO by tou veličinou (která by se měla minimalizovat) mělo být množství informací (větvení, cykly, výjimky, operace…) a ne nominální počet řádků, který toho moc neznamená: roztahaný* kód na 80 řádků bude jistě přehlednější než kód nahuštěný na 50 řádcích – protože to množství informace musí být v obou případech stejné, má-li aplikace dělat totéž, jen v jednom případě je přehlednější, zatímco ve druhém autor onanoval nad svojí schopností mistrně nahustit program na co nejméně řádek a využít všechny exotické možnosti daného jazyka, aby dokázal, že je ovládá

*) např. {závorky} za IF, které někteří považují za zbytečné, deklarování každé proměnné na samostatném řádku, komentování…

[Salamek]

kvalitní kod by měl být co nejmenčí na počet použitých funkcí cyklů atd měl by nýt řádně okomentovaný a odsazený

[xkucf03]

+1

[Kvakor]

... roztahaný kód na 80 řádků bude jistě přehlednější než kód nahuštěný na 50 řádcích – protože to množství informace musí být v obou případech stejné, má-li aplikace dělat totéž, jen v jednom případě je přehlednější, zatímco ve druhém autor onanoval nad svojí schopností mistrně nahustit program na co nejméně řádek ...

To plati jen tehdy, pokud tech 80 vs. 50 radku spociva jenom ve stylu zapisu. Casto se ale stane, ze na tech 80 radcich jsou naproste hlouposti - pouzivaji se neefektivni algoritmy, znovu se "vynaleza kolo", tj. implementuje rutina, ktera je davno uz hotova v knihovnach (to je zle obzvlast u interpretovanych jazyku), nebo se pachaji veci, ktere by dusevne zdravy clovek vyprodukoval leda pod vlivem.

Napriklad zrovna nedavno jsem videl v kodu funkci (ocividne pridanou dodatecne), ktera prevadela jedno male cele cislo na druhe, kde to prvni cislo byl typ produktu (ziskany z databaze) a druhe typ prislusensvi k nemu. Byla dlouha nekolik desitek radku a skladala se temer ze samych if/elseif zanorenych do sebe, porovnani a prirazeni, proste obludnost sama. "Cista" verze stejneho algoritmu by pouzila napr. switch/case, sice by zabrala zhruba stejne mista (spis vice), ale dalo by se v ni krasne vyznat a urcite by se mnohem vic libila jak parseru, tak prekladaci ci generatoru bytecodu.

Ale je tohle reseni optimalni? Ne, je to silenost, na prevod jednoho cisla na druhe je prece naprosto zbytecne pouzivat podobne konstrukce, muzeme napr. pouzit pole ci neco podobneho, pak na nahrazeni mnoha desitek radek staci definice dat (v tomto pripade cca. tri radky) a tri radky kodu (dve z toho na ohlidanim chybneho vstupu). Nebo - jako v tomto pripade - stacilo pridat jeden jediny sloupec do tabulky produktu v databazi (a naplnit hodnotami), upravil se jeden SQL prikaz a prepsala se jedna jedina radka kodu - na miste, kde se volala ona funkce, se priradil z databaze vytazeny typ prislusenstvi, a ona funkce se mohla zcela zahodit, tj, zredukovat na nula radku.

Takze - oprimalizace zapisu algoritmu ("zhusteni zapisu") je spatna vec, sice to muze v nekterych pripadech udelat optimalnejsi kod, ale rozdil je vetsinou minimalni a vysledny "write-only" kod (obvlast je-li v Cecku nebo Perlu) je pak naprosto neudrzovatelny.

Kdezto nahrazeni spatneho algoritmu, budto lepsi verzi, nebo pomoci volani knihoven, je temer vzdy* dobra vec - nejen, ze to vede k zvyseni efektivity, ale vysledny kod je pak vetsinou mnohem citelnejsi a je z nej casto na prvni pohled zdrejme, co dela, obzvlast pri pouziti dokumentovanych rutin z knihoven.

* Ano, existuji pripady, kdy na prvni pohled "horsi" algoritmus je vhodnejsi, nebo kdy je lepsi nahradit knihovni rutiny vlastni verzi, ale takoveto pripady se vyskytuji malokdy (obzvlast ve vyssich jazycich) a ma je smysl delat jen tehdy, kdyz to opravdu ma vyrazny efekt, napr. v nejvnitrnejcich smyckach cyklu.

[xkucf03]

jo, naprosto souhlasím – měl jsem na mysli ten styl psaní. Prostě nízký počet řádek by neměl být cílem, ale jen vedlejším efektem tvého dobrého programování.

[Salamek]

No oni zdrojáku vyprodukují 1 řádek za 6 měsíců ... takže nic moc

[Kvakor]

Pokud ten prvni priklad (ten opakovany test stejne promenne) nenapsal nekdo s mohutnou dusevni poruchou, tak bych to odhadoval na vytvareni podminky pomoci Copy+Paste (nespis puvodne and $zaznam1[jmeno]!='login'). Ocividne se pisatel trochu rozjaril a kdyz mu kod ponekud prerostl pres hlavu, tak se v nem nejspis ztratil a vetsinu puvodnich vlozenych dat tam nechal. V jednom programu jsem videl neco podobneho - bylo tam nekolik naprosto stejnych testu po sobe, ktere byly stejne jako test hned na zacatku, pravdepodobne zbytky po vkladani, ktere uz nebyly prepsany.

K onomu silenemu insertu - kdyz uz musi nekdo neco podobneho udelat, tak je lepsi pouzivat syntaxi SET `sloupec1`='hodnota1', `sloupec2`='hodnota2' .... I kdyz varianta s SET (...) VALUES (...) je nejspis pro parser lepe zpracovatelna a tudiz o kapku rychlejsi, v pripade vetsiho mnozstvi sloupci, do kterych se navic vkladaji velmi podobne hodnoty, je ladit neco takoveho temer jista vstupenka do ordinace doktora Chocholouska.

[xkucf03]

kdyz uz musi nekdo neco podobneho udelat, tak je lepsi pouzivat syntaxi SET `sloupec1`='hodnota1', `sloupec2`='hodnota2' ...

Stejně si většinou ten dotaz předpřipravíš a pak do něj dosazuješ parametry -- tudíž si to musíš stejně odpočítat. Pohodlnější je, když si můžeš parametry pojmenovat (místo aby ses na ně odkazoval indexem), ale to nejde všude.

[Jirka Keresteš]

Hmm, to mi něco připomíná, že by SGWG?

[vlastikroot]

Tesne vedle, SGG

[Salamek]

pokud tím tak SGWG je to samé co SGG

[AraxoN]

Hehe... to ja som kedysi programoval pre jednu americkú spoločnosť, ktorá na titulnej stránke (t.j. na najzobrazovanejšej stránke) hrdo vypisovala údaj o množstve položiek vo svojej databáze. Toto číslo sa získavalo takým spôsobom, že SELECT * FROM tabulka a potom while (mysql_fetch(...)) $pocet++; Pri 400-tisíc záznamoch a tabuľke veľkej asi 500 MB to išlo ako chorý slimák po opici prebudený o tretej ráno tesne pred smrťou hore kopcom po lepidle.

A to bol jeden z lepších kusov kódu - síce neefektívny, ale vracal to čo bolo treba, a nebola v ňom bezpečnostná diera. To sa nedalo povedať o zvyšku kódu na tom portáli...

[Salamek]

no představte si že takhle je psána celá ta hra , na něco podobného narazíte na každém kusu kódu co tam je ... a ještě se ti co to provozují diví že jim to žere 4 jádro bo co to mají a musí mít lomit na online

[slush]

Ach ten sentiment. Zavzpominal jsem si na sve zacatky v PHP . Tim zacatky myslim pravdu jen _zacatky_... Timhle zpusobem se prece neda napsat (a udrzovat) kod delsi nez dve ste radku :).

[Arnost]

 

 HříšníSpameři. Chtěl si revizi kódu, tak tady to máš pár poznámek:

 

package cz.frantovo.hrisniciSpameri;

public class DenniSouhrn 

 

- definuješ serialVersionUID (v revizi 3), ale nezměníš to když přidáš nové položky (revize 20, 26) (tohle je celkem drobnost)

 

- použití java.text.SimpleDateFormat - není to thread safe (viz http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html) - měl by ses vyhnout sdílenému DateFormat

 

- obecně mi příjde že se moc nezabýváš thread safe kódem...

 

- metody setZacatek a setZacatekString - ta druhá je podle mě zbytečná. Ale hlavně - pokud dostane špatný vstup, tak jej prostě ignoruje a nastaví default (kód používající tuhle metodu bych každopádně nechtěl ladit)

 

- setCilString opět ignoruje výjimku - to je podle mě obecně prasárna...

 

- getSouhrn() - poznámka o JSP - kód by obecně neměl předpokládat kdo jej použije (JSP nebo jiné šablonovátko?)

 

-  getSoucty() - obdobný kód jako předchozí bod - to se ta úprava dat pro JSP musí rozkopírovat úplně všude? Chtělo by to nejak promyslet, nebo data odfiltrovat (AOP - Aspect?)

 

- používání loggeru - trochu plýtváš časem, mohl bys nejdřív zkontrolovat jestli je příslušný log level zapnutý (jinak zkontruuješ řetězec který následně zahodíš)

 

- private static Date getVychoziKonec() - tahle metoda vrací aktuální čas, slouží vlastně jako součást kontruktoru (ne přímo, ale vyplývá to z todo jak je třída zkonstuovaná).  Když budeš v budoucnu chtít přidat equals (teď tam není), tak ti to úplně rozbije kód - dvě instance třidy se budou rovnat v závislosti na tom kdy zavoláš getter... Když vytvoříš instanci, kterou serializuješ a pak na obou zavoláš getter, dostaneš jiné hodnoty (což  může záviset na tom jak budeš aplikaci nazazovat, jestli se instance mezi různými vrstvami musí serializovat).

 

Taky to múže způsobit nečekané chyby (když vytvoříš instanci DenniSouhrn, ulozis Soucet a zavolas getSoucty(), tak to najde soucet. Kdyz ale pred ulozenim souctu zavolas getKonec, tak jej nenajde, protože čas je nastaven před čas vytvoření Soucet (to může být obvzlášt vtipné když se getKonec volá v loggeru a logování se vypne... :o)

 

Taky bych tuhle metodu nedefinoval jako static - je pro to nějaký důvod? (kromě toho že to komplikuje přetěžování... taky by bylo lepší volání psát ve formátu Class. getVychoziKonec, místo (this.) getVychoziKonec, aby bylo jasné že je to static)

 

- jestě jednou getSoucty() - když tak na to koukám - ta metoda bude fungovat jinak pokud předtím zavolám gettery (initicalizuju zacatek a konec) a když nezavolám gettery? (Btw, getter by neměl mít vedlejší efekt jako inicializace - opět prasárnička :)

 

 ... to by asi pro dnešek stačílo :) 

 

[kozzi]

Ja bych jen dodal, ze mixování češtiny a angličtiny v názvech není moc pěkné, lepší by bylo imho jen anglické názvy. Ale to je spíš jen kosmetický detail.

[xkucf03]

Kde mixuji češtinu a angličtinu? :o) Snažím se psát důsledně česky* – jen předpony (get, set…) používám anglicky, to jinak nejde, konvence…K té češtině mám svoje důvody, pokusím se o tom někdy něco napsat

*) resp identifikátory píši cesky

[kozzi]

setCilString napriklad.

[xkucf03]

String je tady název datového typu, to se mi nechtělo překládat

[freshmouse]

Hmm, já se setkal i s diakritikou v názvech funkcí. Naštěstí to dotyčná nepsala schválně, ale prostě psala a zapomněla, že je to zdroják... Technický problém s tím není, ale ten psychický dopad...

[xkucf03]

Jaký je psychický dopad? Přijde mi to lepší česky než cesky, protože vypovídací schopnost textu s diakritikou je vyšší. Ale když jsem to posledně zkoušel, tak byly problémy s názvy tříd (souborů) v JARech, ale to jsem ještě používal Windows. Asi ten svůj test zopakuji, třeba to už teď bude fungovat dobře (a ne jen dobre) .

[xkucf03]

definuješ serialVersionUID (v revizi 3), ale nezměníš to když přidáš nové položky (revize 20, 26) (tohle je celkem drobnost)

Program je v dost bouřlivém vývoji, tak tohle neřeším, ale je fakt, že až se to trochu stabilizuje, měl bych UID při změnách tříd měnit, aby plnilo svoji funkci.

použití java.text.SimpleDateFormat - není to thread safe

Opravil jsem – už není statický – to by mělo stačit.

obecně mi příjde že se moc nezabýváš thread safe kódem...

u bean používám scope="request" a instance DAO tříd nesdílím, tak snad tam chyby související s vlákny nebudou… resp. zatím jsem na ně nenarazil

setZacatekString - ta druhá je podle mě zbytečná.

Ty …String se mi taky nelíbí, možná zkusím použít nějaký framework s validací (Stripes…), abych tyhle věci nemusel řešit v kódu.

getSouhrn() - poznámka o JSP

Komentář jsem přepsal: „JSP“ → „prezentační vrstva“

getSoucty() - obdobný kód jako předchozí bod - to se ta úprava dat pro JSP musí rozkopírovat úplně všude? Chtělo by to nejak promyslet, nebo data odfiltrovat (AOP - Aspect?)

Toho společného kódu moc není (jen dva řádky), ale vyčlenil jsem ho do metody → je fakt, že teď kdyby ve třídě přibyla nějaká další citlivá informace, přidá se filtrování na jedno místo. Taky jsem zvažoval, jestli tohle vůbec řešit (nevím, jak často to vůbec někdo řeší) – takhle by to mělo být trochu odolné i proti tomu, že by JSP psal někdo jiný a chtěl zobrazit víc informací, než má.

používání loggeru - trochu plýtváš časem, mohl bys nejdřív zkontrolovat jestli je příslušný log level zapnutý

Možná jo, ale spíš dám přednost přehlednějšímu kódu (bez IFu s log.isLoggable)… v případě náročnějších operací (než formátování data) by tam asi ten IF být měl.

Když budeš v budoucnu chtít přidat equals (teď tam není), tak ti to úplně rozbije kód - dvě instance třidy se budou rovnat v závislosti na tom kdy zavoláš getter

 Nepočítám s tím, že bych je potřeboval porovnávat (on by to ani nebyl moc velký rozdíl, než kdyby se lišily podle toho, kdy byly vytvořeny, místo kdy by se zavolal getter). S aktuálním časem je vždycky trochu problém – třeba v PL/SQL máme pravidlo, že se nemá používat sysdate a místo toho má aktuální datum explicitně vstupovat do procedury jako parametr. Tady jsem si to trochu zjednodušil, protože posílat aktuální datum do beany z JSP vrstvy mi přijde pakárna Taky potřebuji v JSP znát datum, pro které beana poskytne data – a to i v případě, že je datum zadané špatně nebo vůbec – pak chci vědět výchozí datum (pro naplnění formulářových polí začátek a konec). Takže mi přišlo lepší ohackovat gettery v beaně, než přidávat několik ifů do JSP.

Taky bych tuhle metodu nedefinoval jako static - je pro to nějaký důvod?

Když ta metoda nepoužívá nic nestatického, tak ji často nastavím jako statickou, protože pak je jasné, že ta metoda nemění svoje chování v závislosti na netstaických proměnných třídy. Pak taky snáz poznám funkce od metod, což člověka občas inspiruje vyčlenit společné funkce do nějaké knihovní třídy.

getter by neměl mít vedlejší efekt jako inicializace

 Jenže kam dát u webových bean tu logiku? Všechno ostatní, kromě toho getteru se dá obejít (např. voláním setterů v nečekaném pořadí). U takhle jednoduché kombinace JSP-Beana pošlu do beany nějaké parametry od uživatele (set) a pak se JSP zeptá beany na nějaký výsledek (get), ale mezi get a set nic není – takže, kam s tím?

Každopádně díky za kometřář ono je vždycky lepší, když na jeden kód kouká víc lidí než jeden. BTW: nemáš tip na nějaký J2EE open source? (s kvalitním kódem vhodným k inspiraci )

[Daniel Kvasnička ml.]

Všechno ostatní, kromě toho getteru se dá obejít (např. voláním setterů v nečekaném pořadí). U takhle jednoduché kombinace JSP-Beana pošlu do beany nějaké parametry od uživatele (set) a pak se JSP zeptá beany na nějaký výsledek (get), ale mezi get a set nic není – takže, kam s tím?

Nepouzivej primou palbu na JSPcka, to je humac Moje (a rekl bych ze zdaleka ne jen moje) pravidlo je mit JSPcka mimo WEB-INF jen kdyz to opravdu jinak nejde (typicky jen index.jsp, ktery stejne obsahuje jen presmerovani na URL handlovanou Stripes servletem).

JSP beany pouzivam jen jako view helpery pro natazeni dat, ktera potrebuju mit na strance za kazdych okolnosti, bez ohledu na stav nebo dostupnost beany kontrolleru (treba data pro ruzne sidebary a tak).

[xkucf03]

Nepouzivej primou palbu na JSPcka, to je humac

To už jsem udělal u UpozorněníEmailem -- přímo přístupný je jen index.jsp a stránky s jednotlivými komponentami se includují z nepřístupné složky (WEB-INF/casti).

Jasně, Stripes jsou fajn, ale říkal jsem si, že takhle jednoduchá aplikace přece musí jít slušně napsat i s čistými JSPčky, ne? Takže kam s tou logikou v takovém případě -- zatím jsem na to ani od zkušenějších kolegů nedostal uspokojivou odpověď. Nejméně zprasené mi přijde nacpat tu logiku* do getterů. Druhá možnost, co mne napadla je, mít gettery a settery úplně prosté, bez jakékoli logiky a mezi těma dvěma fázemi (set  a get) zavolat ještě jeden setter, který by nic nenastavoval, ale provedl by nějaké zpracování, aby následně volané gettery už žádnou logiku nevykonávaly... možná tohle je správná cesta, ale přišlo mi to už zbytečně složité.

*) není to žádná byznys logika, pořád je jen logika související s prezentační vrstvou.

[Filip Jirsák]

přece musí jít slušně napsat i s čistými JSPčky

Teoreticky by to možná jít mohlo, prakticky si nahrazením JSP za nějaký lepší systém šablon vždy pomůžete. Ono je JSP poněkud nevhodné pro psaní view a naopak se v něm celkem dobře píše logika, takže to nakonec dopadne vždy stejně...

[xkucf03]

Ono je JSP poněkud nevhodné pro psaní view a naopak se v něm celkem dobře píše logika, takže to nakonec dopadne vždy stejně...

hmm, i když mám XML (JSPX) rád, tak se mi v něm moc programovat nechce (psát logiku, větvení, odchtávat výjimky...), takže když už používám jen JSP+Beany, tak se snažím, aby JSP bylo hlavně XHTML šablona s minimem logiky, aplikační logika buď není*, nebo ji dám do EJB -- a ty webové beany pak beru jako takové lepidlo mezi nimi (když už to nejde jinak a něco se musí zprasit, tak obětuji ty webové beany, zatímco JSP a DAO/EJB by měly být napsané hezky -- ale pokud máte někdo nápad, jak neprasit vůbec**, tak sem s tím ).

*) např. při zobrazování obsahu z databáze 1:1, nebo při nějakém jednoduchém filtrování
**) aniž bych do toho musel tahat další framework -- to je potom jiná.

[Filip Jirsák]

Já netvrdím, že by se v JSP psala logika nějak bůhvíjak snadno. Ale view se v nich (podle mne) píše o dost hůř, než třeba ve Freemarkeru, na druhou stranu přidat do JSP logiku není až takový problém (třeba v tom Freemarkeru logiku aplikace nenapíšete, pokud si do šablony nepodstrčíte vhodné objekty -- a když už bych ty vhodné objekty vyráběl, to dám raději logiku rovnou do nich).

[Ladicek]

Záleží o jakou logiku jde, kdysi jsem ve Velocity psal selection sort

[default]

pokud máte někdo nápad, jak neprasit vůbec**, tak sem s tím ).

Já to dělal takto:

• přístup k databázi přes Entity EJB
• logiku aplikace v Session EJB
• Tagliby zapouzdřující logiku
• v JSP(X) použity Tagliby

A funguje to. A nepotřebuješ psát nic Javího v JSP(X).

Vono to JSP(X) je stejně takový nějaký nedodělaný. A JSF je dost cool, ale shodli jsme se, že je stále příliš low-level. Kolega používá JBoss Seam. Já si s tím nehrál, protože mě tyhle webový nesmysly naprosto nezajímaj. Celý je to totiž podle mě špatně a je to jen znásilnění technologií a protokolů. Všechny ty AJAXy, komety… Dejte pokoj!

[xkucf03]

 

Celý je to totiž podle mě špatně a je to jen znásilnění technologií a protokolů. Všechny ty AJAXy, komety… Dejte pokoj!

 jj, taky se mi nelíbí ten trend cpát všechno na web, je to úplně pokroucené... jenže oni to chtějí a nedají pokoj, dokud to nedostanou

 

[Daniel Kvasnička ml.]

Ja nemam moc potrebu hledat nahradu za JSP. Zadne znovuvynalezani kola, je to proste XML s par jmenymi prostory, nic vic. Ovsem je fakt, ze jsem nekolikrat potreboval vygenerovat treba email a nemoznost JSP k tomuhle pouzit jako regulerni sablonovaci system me dost zrala... (ale to se da vyresit mnoha jinymi zpusoby)

[Ladicek]

Ono totiž JSP v podstatě vůbec není šablonovací systém, ale naivně omezen(eck)á syntaxe pro zápis servletu, který bleje stringy. Vždyť to nemá ani podmínku nebo cyklus, a o makrech si může člověk leda tak nechat zdát (proto tam jsou skriptlety a proto existují tagliby). Korunu tomu pak nasazují věci jako podpora lokalizace nebo chování při chybách. Když pak vezmu, že proti veškerým očekáváním jsou Velocity i Freemarker rychlejší (no, to už dneska asi neplatí, ale čert to vem), neexistuje žádný důvod zůstávat u JSP.

[xkucf03]

Jak nemá podmínku?

[Ladicek]

Nemá, musíte použít skriptlet nebo speciální taglibu. Ono vzato kolem a kolem, JSP umí akorát vypsat text nebo hodnotu proměnné a s drakonickými omezeními zavolat javovský kód. Mimochodem psaní vlastních tagů je taky úchvatný prožitek, pámbů s námi a zlý pryč.

[xkucf03]

Jo takhle , ty běžné tagliby beru jako samozřejmost.

<c:if test="${a == b}">
        …
</c:if>

Ta JSP mi nepřijdou jako úplně špatný koncept – prostě si všechno připravíš v beaně, přičemž to není nějaká obecně použitelná beana, ale třída pro tu jednu konkrétní stránku. A JSP jen projde pár cyklů, rozvětví se v něm pár jedoduchých podmínek a obalí data (X)HTML značkami. Jenže jak je do toho potřeba namontovat nějaké validace a ošetřování výjimek, tak už to tak jednoduché není.

A scriptlety nesnáší, neměly by se používat.

[Ladicek]

Ale jo, bez JSTL by to bylo fakt o držku. A zaplať pámbů za skriptlety, když potřebujete ohackovat nějaký problém

[xkucf03]

Naposledy jsem viděl, jak do skriptletu někdo nahackoval System.out.println("============================================"); a další vtipné výpisy.

[Ladicek]

To se mi líbí, logování do normálních šablonovacích systémů tak snadno nedostanu

[Daniel Kvasnička ml.]

Vždyť to nemá ani podmínku nebo cyklus, a o makrech si může člověk leda tak nechat zdát (proto tam jsou skriptlety a proto existují tagliby).

Me se princip taglibu libi a kdykoliv delam v PHP s PHPTALem, tak bych hned METAL makra za tagliby vymenil...

Když pak vezmu, že proti veškerým očekáváním jsou Velocity i Freemarker rychlejší (no, to už dneska asi neplatí, ale čert to vem), neexistuje žádný důvod zůstávat u JSP.

Kdyz me je tak strasne proti srsti ucit se nejakou dalsi "prave-jsem-vymyslel-novy-super-system-a-zachranim-svet" syntaxi :-/ S JSP delam kazdy den a jeste se mi nestalo, ze bych musel pouzit tu starou odpornou syntaxi. Proste pisu XML. Kdyz delam v PHP (PHPTAL), pisu opet XML. Nemam co resit.

[Filip Jirsák]

JSP nemusí být XML, a řekl bych, že ve spoustě případů to ani jako validní XML zapsat nepůjde (pokud se tedy budete chtít vyhnout velkému duplikování kódu). Ale jak už tu někdo psal, JSP je vlastně způsob zápisu, který umožňuje napsat do zdrojáku servletu texty po větších kusech. Pro view tedy nic moc.

[Daniel Kvasnička ml.]

JSP nemusí být XML, a řekl bych, že ve spoustě případů to ani jako validní XML zapsat nepůjde (pokud se tedy budete chtít vyhnout velkému duplikování kódu).

Jako treba?

[Filip Jirsák]

Třeba jednoduché "pruhování" tabulky -- tj. potřebuju podle nějakého kritéria (třeba parita) řádku nastavit nebo nenastavit atribut class. Tedy chci následující výstup:

<tr><td>obyčejný řádek tabulky</td></tr>
<tr><td>obyčejný řádek tabulky</td></tr>
<tr class="strong"><td>důležitý řádek tabulky</td></tr>
<tr><td>obyčejný řádek tabulky</td></tr>
<tr class="strong"><td>důležitý řádek tabulky</td></tr>

Buď dám do podmínky celý řádek <tr>...</tr> a v alternativě jej celý zopakuji s přidaným stylem, nebo dám do podmínky jen úvodní tag nebo jeho část, ale pak už to nebude validní XML.

Obecně se to dá popsat tak, že jednotlivé části kódu (mezi scriptlety) musí být validní fragmenty XML, jakmile potřebuju upravit jen část fragmentu, musím jej zkopírovat celý.

Neřeším teď, že zrovna tu tabulku jde udělat jinak -- třeba přiřadit třídu i druhému typu řádků. Výstupem JSP má být (X)HTML, jaké si nadiktoval webdesigner, ne že ho budu upravovat tak, aby se mi dobře psalo zdrojové JSP.

[default]

Výstupem JSP má být (X)HTML, jaké si nadiktoval webdesigner, ne že ho budu upravovat tak, aby se mi dobře psalo zdrojové JSP.

No, tady si dovolím trošku nesouhlasit. Všichni by měli pracovat dohromady a vše by se mělo tak nějak zkloubit dohromady.

My se tady třeba snažíme s businessem spolupracovat docela úzce. Prostě některé požadavky se dají naimplementovat (jako vše), ale když přihoděj další milion účtů na zpracování, tak se nevejdou do časového okna. Takže musí slevit oni i my.

Ale to je spíš otázka metodiky řízení projektů, než limity JSP…

[Daniel Kvasnička ml.]

Zopakovani toho radku v alternative je podle meho nejlepsi zpusob. Sice to zni jako neoptimalizovane reseni, ale rozhodne to pak neni write-only kod jako kdyz se treba napise ternarni operator na misto, kde ma byt atribut a zrusi se tim XML povaha toho JSPcka. Nejen, ze pokud je v kodu takovych veci vice, stava se to cele naprosto neudrzovatelnou zmeti znaku, ale hlavne se tim vazete na syntaxi JSP a tim jste skoncil. Kdyz to pisete jako XML, mate vzdycky moznost z toho udelat cokoliv jineho (pomoci XSLT nebo tak).

Nehlede na to, ze kdyz to je XML, muzete to editovat v kazdem blbouckem editoru, protoze i takovy zpravidla ma alespon to zvyrazneni XML.

Ja myslim, ze by se mela zmenit specifikace JSP pokud jde o chovani jsp:attribute. Nemelo by byt nutne mit ten tag jako primeho potomka jsp:element, ale mel by se vazat na nejblizsiho predka instance jsp:element.

[Filip Jirsák]

Zopakovani toho radku v alternative je podle meho nejlepsi zpusob. Sice to zni jako neoptimalizovane reseni, ale rozhodne to pak neni write-only kod jako kdyz se treba napise ternarni operator na misto, kde ma byt atribut a zrusi se tim XML povaha toho JSPcka.

Můj názor na to je přesně opačný. Pokud uvnitř toho řádku budete mít kód na 100 řádků, který musíte zduplikovat, je to dost k ničemu. Pak vám někdo řekne, že tam máte překlep, vy si slovo vyhledáte, opravíte, a už si nevzpomenete, že po 100 řádcích kódu se to opakuje a je to potřeba opravit i tam.

Nejen, ze pokud je v kodu takovych veci vice, stava se to cele naprosto neudrzovatelnou zmeti znaku, ale hlavne se tim vazete na syntaxi JSP a tim jste skoncil. Kdyz to pisete jako XML, mate vzdycky moznost z toho udelat cokoliv jineho (pomoci XSLT nebo tak).

Právě proto nemám rád JSP. S Freemarkerem mám prostě HTML, do kterého doplním značky šablony, a je hotovo. Nemusím syntaxi zdrojáku nijak upravovat, dál ho můžu upravovat skoro každým HTML nebo XML editorem...

[Daniel Kvasnička ml.]

Pokud uvnitř toho řádku budete mít kód na 100 řádků, který musíte zduplikovat, je to dost k ničemu.

Pokud kvuli jine hodnote atributu opakujete radek, ktery ma v sobe tolik obsahu, je na miste pouzit jsp:include, abyste nemusel tolik kodu duplikovat. A nebo si ten radek napsat jako tag file. Navic texty jsou casto kvuli lokalizaci sdilene a nejsou vubec v JSPckach, ale treba v properties souborech. Preklepy pak opravujete jednou a to tam.

Nemusím syntaxi zdrojáku nijak upravovat, dál ho můžu upravovat skoro každým HTML nebo XML editorem...

Ale ten skoro kazdy editor nerozezna text od znacek. Zato u JSP XML ano, protoze ty direktivy jsou proste tagy a ty jsou zobrazene jinak nez text.

[Filip Jirsák]

Pokud kvuli jine hodnote atributu opakujete radek, ktery ma v sobe tolik obsahu, je na miste pouzit jsp:include, abyste nemusel tolik kodu duplikovat. A nebo si ten radek napsat jako tag file.

Takže pak musím JSP podřídit celý svůj kód a rozsekat jej na malinké části. Děkuji, nechci.

Ale ten skoro kazdy editor nerozezna text od znacek. Zato u JSP XML ano, protoze ty direktivy jsou proste tagy a ty jsou zobrazene jinak nez text.

Jenže to HTML okolo jsou taky tagy, takže se mi bude do sebe motat JSP a HTML. Já se na šablonu dívám jako na HTML, kde je sem tam přidaný nějaký kód šablonovacího systému, který by mi neměl moc překážet.

[xkucf03]

Od toho jsou v XML jmenné prostory, aby se různé značky do sebe nemotaly.

[Filip Jirsák]

On umí nějaký editor obarvovat každý jmenný prostor XML jinak? Který?

[xkucf03]

Jestli jinak barevně, to nevím (i když problém by to nebyl), ale Netbeans mi zobrazují značky JSP (a dalších jmenných prostorů) tučně, zatímco HTML značky jsou netučně. Každopádně mi ale přijde lepší XML syntaxe, než HTML do kterého jsou přidané nějaké další značky (s jinou syntaxí).

[Daniel Kvasnička ml.]

Takhle obecne asi zadny (do Eclipse jsem to psal jako feature request, ale bylo mi receno, ze je to celkem netrivialni zalezitost a ze je o to asi malo zajem). Ale editor JSP v Eclipse od sebe barevne odlisuje tagy z XHTML a JSTL.

[Daniel Kvasnička ml.]

Takže pak musím JSP podřídit celý svůj kód a rozsekat jej na malinké části. Děkuji, nechci.

O malinkych castech nikdo nemluvil. Vy jste mluvil o 100-radkovem kodu renderujicim radek tabulky.

[Daniel Kvasnička ml.]

Tak to upozorneni emailem jeste podle tvych vlastnich slov neni hotove, tak se to tezko hodnoti, ale ta aplikace HrisniciSpameri by klidne Stripesy snesla Muj nazor

Jinak pak mas jeste porad moznost pouzit ciste servlety, ulozit do req a forward ... Pokud by slo o dva tri formulare, tak to podle me je lepsi nez to mastit do tech getteru/setteru.

[manasekp]

hm, ja treba radsi napisu naprosto prasacky a neoptimalizovany kus(v mem pripade vetsinou php) kodu ktery me napadne hned, nez abych dlouhou dobu premyslel jak to udelat efektivneji/jinak/lip. Vysledek - usetrim muj cas a pridam praci serveru kteremu to nevadi(nestezoval si ani kdyz sem nastavil max dobu provadeni skriptu na 2000sec ps. samozrejme to plati pro veci ktere pisu vetsinou pro sebe, byt to soucast nejake zakazky tak bych mozna zacal premyslet o optimalnejsi variante.

[kozzi]

ale to je zbytecny, zakaznik tomu precivetsinou nerozumi, "hlavni ze to nejak jede", to ze je to spraseny "nevadi", vsak co. Nikdy uz ten kod potrebovat "nebudu". "A upravovat ho taky nebudu chtit ze. Je to preci zbytecny"

[manasekp]

jo zakaznik tomu sice nerozumi ale co kdyby se to nahodou dostalo do ruky nekomu kdo tomu rozumi Pak uz by ode me nikdo nekoupil ani wordovy dokument

[rincewind]

Na to jsem narazil, kdyz jsem prevzal jedny webovky - obsah byl generovan z MS Excelu, myslel jsem, ze to nerozdycham (a to jsem puvodne chtel jen premigrovat obsah a nechat to zit dal), hold zacalo se na louce zelene

[snajpa]

Já se většinou můžu na nějaký extrémní optimalizace vykašlat, pro mě je důležitá přehlednost kódu, (i když moc nekomentuju) abych se v něm vyznal i za pár měsíců.

[freshmouse]

Je to mimo téma, ale znáte něco, čím by se daly spravovat layouty v JavaServer Faces (ideálně něco ve stylu Stripes)? (Faces používám jen chvilku, přičemž jsem si je sám nevybral -- navíc je to nějaká stará aplikace se starými Faces ).

[finc]

Na rozdeleni layoutu a vubec UI vrstvu jsem pouzival Facelets. Jedna se o sablonovaci system, ktery by v novejsi verzi JSF mel byt primo nativne.

Jinak JSF je peknay moloch, ktery kdyz vidim, tak jdu do kolen.

[Petr Masopust]

JSF je pouzitelne snad pouze v kombinaci s facelets a dalsich par veci tam doplnuje seam.

Btw stripes je uplne jiny typ frameworku (request/response vs. komponenty).

[freshmouse]

> Btw stripes je uplne jiny typ frameworku (request/response vs. komponenty).

Já do toho příliš hluboko nevidím; mým úkolem je práce s JSP nebo nějakou nadstavbou; občas napíšu nějakou třídu atd. Z tohoto pohledu jsou pro mě JSF a Stripes docela podobné technologie. Jak si to vnitřně implementují, to mě příliš nemusí zajímat. Zejména o JSF nic nevím, přišel jsem k projektu a musel jej začít hned upravovat; na studium bohužel není čas (ale naštěstí neupravuju architekturu, návrh atp., jen drobnosti)...

[finc]

Ten zpusob muze byt odobny, ovsem skutecne se jedna o jiny typ frameworku. Asi nema smysl rozebirat podstaty. Nejlepsi je, znat zaklad (JSP-Servlet) a pote podle toho hodnotit dalsi nadstavby. Pokud mas moznost volit jakoukoli nastavu, jdi bud do Stripes nebo do Apache Wicket. Ten druhy framework pouzivam dost aktivne a jsem s nim nadmiru spokojen.

Jinak pro JSF mas nekolik dalsich nadstaveb. Prvni z nich, asi nejouzivanejsi je prave facelets na sablonovani. Pote jsou to napr RichFaces jako zdroj ruznych kompoent a v posledni rade napr. Seam, ktery se da vyuzit nad JSF. Jeho vyhodou je samotny fakt, ze Dependency Injection resi po svem a pravdou je, ze omnoho lepe se s nim pracuje nez s obycejnymi Backing Beans pro JSF.

Ale pokud tomu nerozumis, tak nakup knihy, stahni si ruzne materialy z netu a studuj. Obycenym psanim kodu se zde tolik nenaucis. Neni to PHP.

[freshmouse]

> Nejlepsi je, znat zaklad (JSP-Servlet) a pote podle toho hodnotit dalsi nadstavby.

S tím se samozřejmě nedá než souhlasit.

> Pokud mas moznost volit jakoukoli nastavu, jdi bud do Stripes nebo do Apache Wicket.

Možnost volit nemám; používáme Stripes. Teď jsem mimořádně dostal na starost něco v těch Faces... Je to malý projektík. Popravdě nevím, jestli se mám o Faces hlouběji zajímat jako o zajímavou technologii, nebo nějak doklepat (tím nemyslím odfláknout!) tento projekt a pak na ně zapomenout...

[Petr Masopust]

Stripes je fajnovy framework, ale JSF je tzv. "standard" - jinymi slovy jsou v tom prachy. Schvalne si porovnej kolik najdes nabidek prace kde chteji stripes a JSF...

[finc]

V Jave se dneska snazi psat kazdy druhy. Podle toho to taky tak vypada. Stesti je, ze takovi autori vetsinou po case zacnu Javu nesnaset a tvrdit, ze je to jazyk a platforma nahovno. Diky tomu se alespon castecne takovi "programatori" eliminuji :)

Jinak deleni logiky je vec, kterou clovek oceni az ve chvili, kdy ji skutecne umi dobre rozvrhnout. Jedna vec je MVC na urovni frontendu aplikace a neco jineho je vrstveni na urovni J2EE s nejakym DI kontejnerem (EJB, Spring). MVC vzor dnes jiz nabizi i takove PHP WEB frameworky. U Javy je to jiz zakladni JSP.

Jsem rad, ze jsem takovy kod ve sve aplikaci nikdy neobjevil. Jsem rad, ze i po par letech Javu poste miluji :)

[freshmouse]

> Jinak deleni logiky je vec, kterou clovek oceni az ve chvili, kdy ji skutecne umi dobre rozvrhnout.

Podle mě to ocení spíš tehdy, když dostane na správu nějaký pořádně zprasený rozsáhlý projekt (nejlépe vytvořený před lety s postupnými zásahy nejrůznějších lidí a s postupně "našroubovanými" různými technologiemi). Tak se z ateistů stávají hluboce věřící.

[Neasi]

Nejcasteji vkladam sql do adresniho radku :)

[Ladicek]

Ale prosím vás, něco podobného jsem napsal xkrát a milióny dalších lidí jakbysmet. Koukněte třeba do Pentaho BI Platform, tam jsou věci Jsou prostě situace, kdy s něčím takovým nemám problém

[xkucf03]

Pozoruhodné také je, jak si načte taglib sql, ale pak ho stejně nepoužívá a místo toho píše ty neskutečně hnusné skriptlety. Tenhle taglib taky není žádný zázrak, ale na nějaké prototypy nebo prvotní pokusy se hodit může (asi nejjednodušší způsob jak dostat data z databáze do HTML) – takže když už ty vrstvy takhle zploštit, tak použít alespoň ten <sql:query>, což dá nakonec i méně práce a přitom je to o třídu lepší řešení.

.

[KS]

Bohužel takto se prasí v práci do které jsem nastoupil, což jsem při přijetí nevěděl. Pokus přesvědčit někoho aby to dělal lépe není možné. Ještě na člověka čumí jak na debila, proč to dělat takhle složitě, "vžyť takhle to přece taky funguje". Používaní RAII konceptu v C++ je pro ně něco zcela nepochopitelného. "A ty jako věříš že to funguje?", ptal se mě nadřízený programátor. Je na čase odtamtud zmizet.

Díval jsem se na ty projekty, které odkazuješ. Máš to napsané opravdu pěkně. Víc takových lidí, kteří chtějí dělat věci lépe. Jediné co bych udělal jinak je způsob, jakým se z těch DAO objektů získávají data. Vracíš vždy kolekci se všemi požadovanými daty. Místo toho bych vracel iterátor, který by dával konzumentovi záznamy po jednom. Většinou není třeba udržovat všechny záznamy v paměti najednou, nehledě na to, že konzument si třeba v polovině záznamů rozmyslí, že ty další už vidět nechce.

 

[xkucf03]

Ještě bych měl doplňující otázku k anketě na zdejší aplikační programátory: co říkáte na SQL dotazy uložené v databázi? Když mi o tom poprvé někdo povídal, koukal jsem na něj jako na blázna… Ale ono to nakonec není tak špatné: dotazy se načtou jednou, takže s výkonem problém nebude a při změně datového modelu pak stačí spustit jeden skript, který jednak upraví databázové objekty a jednak přepíše SQL, které používá aplikace → takže se nám spíš nestane, že bychom provedli změny v databázi a zapomněli aktualizovat SQL v aplikaci na novou verzi

[default]

SQL v databázi prosím NÉÉÉ. :-/

[xkucf03]

A podělíš se s námi o důvod?

(zatím jsem to nikde nerealizoval, SQL píšu do XML souborů a dříve jsem je psal přímo do zdrojáku)

[JS]

Ze by Russelluv paradox? Aneb jakym SQL dotazem prectu databazi, jsou-li v ni ulozeny vsechny dotazy?

[xkucf03]

Tenhle přístup samozřejmě předpokládá, že máš jeden SQL dotaz v aplikaci (nebo v nějakém souboru) a pomocí něj natáhneš všechny ostatní dotazy z DB do mezipaměti. Ten základní dotaz přistupuje k jednoduché tabulce, která se v čase němění, takže ani ten dotaz se nemusí měnit.

[AraxoN]

Podľa mňa je šanca, že zabudneš na dotaz uložený v databáze, rovnaká, ako že zabudneš na dotaz uložený v XML. Ukladať dotazy do databázy je presne ten druh "clever" kódu, vďaka ktorému sa aplikácia stane v budúcnosti neudržiavateľnou. Jedna programátorská poučka hovorí, že debuggovanie a úpravy kódu sú trikrát zložitejšie, než jeho prvotné napísanie. Pri písaní kódu by si sa preto nemal snažiť ho napísať tak prešpekulovane ako len vieš (na hranici svojich schopností), lebo neskoršie ladenie a rozširovanie už v Tvojich silách nebude.

[xkucf03]

No, jde o to, že teď mám něco jako framework*, co mi umožňuje snadno načítat SQL dotazy z XML souborů, které se jmenují stejně, jako třída, která tyto dotazy používá. A tenhle framework by se dal přepsat tak, aby SQL nenačítal ze souborů, ale z databáze – neznamenalo by to méně přehledný kód.

To zapomenutí aktualizace dotazu jsem myslel tak, že by došlo k nasazení změn databáze, ale nedošlo by k nasazení nové aplikace (nebo naopak), tudíž SQL by stále počítalo se starými strukturami – kdyby bylo SQL v databázi, tak se tohle nestane, protože jedním skriptem bych aktualizoval jak ty struktury, tak dotazy.  Na druhou stranu s těmi XML soubory se pracuje celkem dobře a dobře se dají verzovat…

*) nadneseně řečeno

[default]

No, já tady dělám s aplikací, která má dotazy uložené v databázi. Celá ta aplikace je jen takový run-time pro tyto dotazy. A objektivně musím říci, že horší řešení jsem snad ani neviděl. Problém je např. jen najít dotazy, které využívají nějakou tabulku nebo sloupec. Místo grepu musím používat SQL klienta a psát dost otřesné dotazy (vpodstatě parser SQL napsaný v SQL). Navíc ta aplikace používá placeholdery pro poddotazy (i pro tabulky a sloupce), což je o to složitější.

Dobrá, to bychom měli vývoj za sebou. A co deployment?

OKi, potřebuji nainstalovat produkt u zákazníka. Dobrá, udělám sadu instalačních skriptů pro založení tabulek a nalití dat. Už vidím ty INSERT INTO … VALUES ('SELECT … FROM ………'). Podpora escapování? Jak jako chceš takový bastl spravovat? Editovat v SQL klientovi a pak unloadnout do SQL? Editovat a verzovat přímo tyto SQL skripty? Vývoj dalšího nástroje a dalších chyb? Dobrá, proč ne.

Další možností je začínat z dumpů. Ty jsou zpravidla binární (Oracle, SyBase, DB2) a tudíž se s nimi nedá dost dobře zacházet. Navíc tyto dumpy jsou zpravidla vázány na konkrétní verzi importního a exportního nástroje, takže potřebuješ stejné verze ve vývojovém a testovacím prostředí, jaké používá tvůj zákazník. O verzování binárních blobů ani nemluvím.

No, není to easy. Ano, uznávám, jde to vyřešit — jako ostatně všechno —, ale proč trávit čas vývojem něčeho, co bude ve finále suplovat již hotové a leta odladěné nástroje (grep, sed, awk, svn…). Beztak stejně podle mě dojdeš k závěru, že ty SQL dotazy musíš mít někde v souborech. Tak proč ty soubory nezkopírovat při kompilaci rovnou do aplikace, ale generovat z nich něco, co je nahraje do databáze?

Tohle je má zkušenost. Přeji hodně štěstí.

[Ladicek]

Using JDBC directly should be a sackable offence. Ale lidi se nepoučí.

[default]

Já tady dělám s aplikací, která má vlastní connection pooling. Tak si vyber, co je lepší.

Celkově je ten software krásná sbírka anti-patternů. Když pominu naprosto chybné použití bloků try … catch … finally — — — instalace aplikace podle manuálu:

1. nainstalovat aplikační server (ehm — servlet container)
2. nadeployovat aplikaci z WARu
3. vypnout aplikáč
4. v adresáři webapps/application-context/properties/ přešukat konfiguráky
5. zapnout aplikáč
6. tento krok je můj: modlit se

Mimochodem — připojení do databáze se řeší právě v těch konfigurácích. Hezky od podlahy: IP, port, uživatelské jméno, heslo, JDBC connection string…

A taky to jde.

[xkucf03]

LOL, bod 4 mě dostal. Hlavně že je veselo, ne?

[xkucf03]

IMHO se takhle hláška hodí hlavně do prezentací a přednášek, aby probudila spící obecenstvo (jak slyší vyhazov, zpozorní).

Jenže ono to bez práce s JDBC nejde – vždycky se používá, záleží jen, na jaké úrovni abstrakce se člověk pohybuje – když nepoužiji nějaké ORM, tak si pravděpodobně budu psát svoji DAO vrstvu a použiji tam… JDBC.

(rozhodně ale nechci obhajovat prasácké použití JDBC a zapomenuté zavírání spojení atd.)

[Ladicek]

když nepoužiji nějaké ORM, tak si pravděpodobně budu psát svoji DAO vrstvu a použiji tam…

Spring JdbcTemplate! Boha, jak vůbec někdo mohl navrhnout takové API, jako je JDBC, jediná horší věc v javovské standardní knihovně je Date a Calendar.

[xkucf03]

A ten JdbcTemplate používá uvnitř co?

…JDBC. Jak skandální, všechny programátory Springu by měli vyhodit!

[Ladicek]

Ehm, ehm, jak mám tohle slušně nazvat? Demagogie?

[podlesh]

Boha, jak vůbec někdo mohl navrhnout takové API, jako je JDBC, jediná horší věc v javovské standardní knihovně je Date a Calendar.

Asi to byla řečnická otázka, ale stejně odpovím: tak, že vzal ODBC

[Ladicek]

Ouvej. Calendar je prý zase okopírovaný z ICU, to je asi taky pěkný porno

[xkucf03]

Pořád lepší než mít pro každou databázi sadu metod (mysql_connect, mysqli_connect, pg_connect...). Jasně, teď už tam mají PDO -- ale zajímavé je, kolik PHP programátorů ani netuší, že něco takového existuje.

[xkucf03]

...lépe řečeno funkcí.

[razor]

Drobnost k HrisniSpameri. Všim jsem si že používáš Class type misto Interface type u kolekce. java/HrisniciSpameri/src/java/cz/frantovo/hrisniciSpameri/dao/SouhrnDAO.java - getSoucty

[xkucf03]

Díky za připomínku. Opraveno.