Re: Co teď letí v Javě na web a verzování?
Dne Sun, 06 Feb 2011 15:58:15 +0100 Pecinovský Rudolf rudolf.pecinov...@i.cz napsal/-a: dotyčný naučil jako první, je v jeho programech (v libovolném jazyce) k vysledování ještě dlouhou dobu. Souhlasim, ale... kdyz by napr. nekdo cetl muj kod, mohl by si myslet, ze jsem se ani po 20+ letech nezbavil assemblerovskych navyku, kdyz vyhodnocuju podminky stylem, odpovidajicim v podstate vetvi posit v Jacksonove backtrackingu misto abych je hnizdil do sebe. Ale ja to delam umyslne, ac se to quitovani jiste strukturovanym puristum nelibi, protoze to povazuji za citelnejsi a udrzovatelnejsi kod s mensi nachylnosti k chybam. A v tom je právě problém. Přecházíš-li na jazyk postavený na jiném paradigmatu, může ten přechod docela dlouho trvat. Souhlasim, ale ja v tomto pripade nemluvim o zasadni zmene paradigmatu jako napr. pri prechodu z proceduralniho jazyka na deklarativni. Pro tuto diskuzi jsem predpokladal, ze zustavame v OO svete. zkušeného programátora 12 až 18 měsíců, přičemž čím zkušenější, tím déle mu trvá, než se zbaví starých zvyků a začne programovat opravdu podle nového paradigmatu. To se udava, ale osobne s tim mam problem: - Kdo je to ten programator? Co predstavuji ty jeho zkusenosti? Umel napr. nejakou (strukturovanou) metodiku? Jestli ano, mohou se mu ukazat rozdily s novou ev. se da ukazat, co ze stavajicich znalosti muze zuzitkovat a treba vlozit jako uvod Jacksonovo JSD s JSP... Umel psat reusable kod? Bude to umet i v Jave a kdekoli jinde. Zna svet XML+XSD+XSL? Urcite to zuzitkuje. Umel pouzivat spravne exceptions napr. v ADA? Bude je umet pouzivat s minimalnim usilim i v Jave, Pythonu a kdekoli jinde, totez regexy, DB connectivita, persistence, marhshalling/unmarshalling, multithreading/multitasking a ja nevim co jeste. - Co v tech 12-18 mesicich ma zvladnout? Napr. pri prechodu do OO sveta nejakou metodiku? Jacobsonovu OOSE, Coad/Yourdanovu OOAD, Rumbaughtovu OMT, Jacksonovu JSD, nejakou jinou? Nebo vsechny dohromady vcetne jejich proscons? UML nebo neco jineho pro modelovani, nejaky konkretni OO jazyk a nejake fasady, nebo nekolik OO jazyku soucasne? Kde a jak si to tech 12-18 mesicu bude osvojovat? atd. atd. Program zpravidla navrhuje nekdo, kdo zna odpovidajici metodiku pro dane paradigma a kdyz ji nezna, tak tezko bude v roli nekoho, kdo ma zasadni vliv na to, jak bude reseni vypadat. A kdyz nastoupi do teamu, kde takoveho analytika maji, tak v pripade OOD v podstate dostane tridy s metodami navrzene, dostane radu hotovych knihoven, nekdo tam bude nejspis dohlizet na kvalitu kodu atd., takze neni ponechan s novym paradigmatem svemu osudu a nema prilis velky prostor pro matlani nejakym neslucitelnym stylem... Naopak ma docela dobrou sanci rychle vstrebat, jak to ma spravne vypadat, zejmena kdyz si k tomu studoval odpovidajici metodiku. Řekl bych, že přechod ze staticky typovaného a dynamicky typovaný jazyk bude někde uprostřed. Asi jej dostaneš pod kůži dříve než za uvedených 12 měsíců, ale za týden to nebude. Viz vyse: pokud ten clovek mel odpovidajici znalosti z OO sveta v prostredich se silnou typovou kontrolou, vlastni dynamicky OO jazyk by mu IMHO nemel delat problemy (a proto jsem psal ten puvodni prispevek). Jestli si to pamatuju, tak kdyz jsme vybirali Python, precetli jsme 2 prirucky a kodovaci standard, abychom psali stejne jako Pythomci - dohromady 500+ stranek - cili par hodin. Trochu jsme jako proceduralni hlavy plavali ve funkcionalnim programovani a krev nam hodne pilo, kdyz se clovek pri prirazovani hodnoty spletl v nazvu atributu, tak misto chyby obohatil tridu o novy atribut :- (tuhle vlastnost bych z jazyka vykopal a zavedl pro to explicitni prikaz - to se strasne spatne hledalo). Jinak s kontrolou datovych typu az za behu to nebylo tak zle. Co nam zabralo dost casu bylo zvladnout framework Django, abychom v nem dokazali udelat, co jsme potrebovali - to byly tydny. Taky prohrabat se knihovnama byl obcas problem (tam by se docela hodila nejaka kucharka programatora jako napsal Darwin javistum). No to jsem toho naslintal... Uz radsi skoncim a jdu delat neco uzitecneho ;) pf
Re: Co teď letí v Javě na web a verzování?
Dne Tue, 08 Feb 2011 17:57:29 +0100 Pecinovský Rudolf rudolf.pecinov...@i.cz napsal/-a: Takový člověk není programátor, ale pouhý kodér. V pocatecnich stadiich uceni se novemu paradigmatu to asi neni nic proti nicemu. Vycházím z průměrného profilu účastníka našich přeškolovacích kurzů [...] A tam bych tak optimistický nebyl. Asi by se dala vyslovit hypoteza, ze ucastnik preskolovaciho kurzu bude pod programatorskym prumerem, ale pripoustim, ze budes realite bliz nez ja. pf
OT: Re: Co teď letí v Javě na web a verzování?
Dne Fri, 04 Feb 2011 14:28:33 +0100 Oto Buchta ta...@buchtovi.cz napsal/-a: 2011/2/4 Petr Fejfar petr.fej...@seznam.cz: výsledkem byla nejrychlejší Beethovenova devátá na světě :-D Malem bych zapomel. Tohle jsem nepochopil (je bezne, ze ruzni digirenti hraji stejne dilo ruzne rychle. A treba Vaclav Talich v prvni nahravce Ceske filharmonie v roce 29 nahral Mou vlast za 79 min, zatimco v roce 56 za 73 min, takze rozdil je skoro desetina a AFAIK je to taky nejrychlejsi nahravka Me vlasti na svete (zpravidla se dirigenti drzi mezi 75-77) :-O Ale asi je to tim, ze me Fulghum nijak neoslovil. pf
Re: Co teď letí v Javě na web a verzování?
Dne Fri, 04 Feb 2011 14:28:33 +0100 Oto Buchta ta...@buchtovi.cz napsal/-a: Souhlas. Ale 'zažiješ' to asi těžko za dvě hodiny a to je to, oč tu běží No to nevim: ja psal tu poznamku v kontextu zacinani s jinym jazykem a tam IMHO programatorovi musi stacit par hodin na to, aby byl schopen po ruce s dokumentaci zacit v tom jazyku rozumne psat. pf
Re: Co teď letí v Javě na web a verzování?
Dne Thu, 03 Feb 2011 06:39:24 +0100 Libor Jelinek ljeli...@virtage.com napsal/-a: Jak se muzes docist ve threadu Off Topic - Oracle/Java/Linux zkratka ala LAMP? tak RoR ;)
Re: Co teď letí v Javě na web a verzování?
Dne Thu, 03 Feb 2011 11:27:03 +0100 Libor Jelinek ljeli...@virtage.com napsal/-a: A tedy JSF jsou podle vás zcela mrtvé? Mám tedy zkusit buď Wicked nebo GWT (Google Web Toolkit)? Na to ti nedovedu odpovedet, protoze v Jave mam zkusenosti pouze s Wicketem, ktery se nam jevil na zaklade 'teoretickeho' porovavani ruznych frameworku jako nejlepsi a rok jsme v nem delali, takze se muzu akorat podelit o osobni zkusenosti: 1. Uz pres rok v Jave nedelam, ale pred tema 2 roky byla jeho free dokumentace slaboucka a bez porizeni si literatury by to vubec neslo: - Enjoying Web Development with Wicket mi prisla dobra na uvod - Wicket in Action popisuje radu dulezitych technik, ale styl jakym je napsana jsem jen tezko vydejchaval 2. Problemy zpravidla dela pochopeni modelu, coz je zalezitost persistence stranek. Na foru nebo nekde se doctes, ze to nekteri jedinci nepochopi ani za 3 mesice. Nam v tomto smeru delalo velke problemy transakcni zpracovani pres nekolik stranek. Obecne bych rekl, ze Wicket ma pozvolnou krivku uceni (v puvodnim vyznamu toho slova - uci se to pomalu) Ale jak do toho clovek proniknul, tak se s tim delalo dobre. Hodne se nam libilo oddeleni grafickeho navrhu od programu a 100% kontrola nad lokalizovanymi texty v .xml, ne jako v GetTextu. Jeste nas trochu zlobilo vyskladani stranky z abstraktnich panelu - pristoupili jsme k tomu jako k obecne desktopove aplikaci, kde se naplno pouzije reusibilita a konkrektni look a polohu na obrazovce tomu daji vytvarnici s CSS, abychom vyuzili oddeleni designeru ksichtu od programatoru a logiky. A to jsme nemeli delat, protoze s tim byly na ruznych browserech potize. S tim jsme hodne bojovali a zjednodusovali layout a hledali, ktere styly poradne nefunguji. 3. Taky s ajaxifikaci byly velke problemy, ale to se netyka ani tak Wicketu jako stavu tenkrat dostupnych komponent do browseru - museli jsme nakoupit literaturu k jQuery, nastudovat a delat si nektere komponenty sami. Ale stejne problemy bychom meli v Pythonu a Djangu a kdekoli jinde. pf
Re: Co teď letí v Javě na web a verzování?
Dne Thu, 03 Feb 2011 12:37:36 +0100 Roman Hrivik ro...@hrivik.com napsal/-a: Tiez som cakal ze tu poleti hlavne Spring, Hibernate. No aby nedoslo k pomyleni: my pod tim Wicketem taky pouzivali Spring na dependency injection, JPA a Hibernate na persistenci. A na vyvoj Eclipse s pluginem pro SVN Maven. Ja teraz dost robim XML, XSLT, BPEL a ine XMLoviny :-) Od Javy daleko. Niekedy mi je z toho uz zle. Se ti ani nedivim. Ozaj, to by ma zaujmalo kolki su tu vysluzili Javisti, ze robili v Jave a uz nerobia ? Ja se nepovazuju za Javistu ani za jineho -istu. Ted uz pres rok v Jave nedelam a vypada to, ze jeste nejaky rok nebudu. Abych byl uprimny, vubec mi nechybi - nemam ten rozvlacny jazyk rad ;) pf
Re: Co teď letí v Javě na web a verzování?
Dne Fri, 04 Feb 2011 01:39:44 +0100 Oto Buchta ta...@buchtovi.cz napsal/-a: No kdyz jsem to rozpoutal, tak jeste par poznamek Člověk se naučí onen jazyk teprve tehdy, když si bude vždy nastopro jistý, že to, co napíše, bude dělat přesně to, co chce, aby to dělalo. To, že to stejně bude dělat něco jiného, je vedlejší :-D Jenomze pokud bys podminil prechod na jiny jazyk nabytim jistoty, tak to bys na zadny jazyk nemohl prejit, protoze tu jistotu nabydes jedine tim, ze ten jazyk jeho pouzivanim 'zazijes' :) Na téma syntaxe na pár hodin - doporučuji zamyslet se nad přechodem z Pascalu na Perl. Nebo z Basicu na LISP či Fortranu na Javu (ano, tady to kapku pokulhává, ale napsat jsem to prostě musel) Ono ani přechod z Perlu na Python není žádný med. Asi mam pohled zkresleny 30+ lety praxe, kdy jsem programoval kde v cem, vcetne jazyku ktere uvadis, nicmene uz muj guru z pocatku kariery rikal 'muj sef se ucil Basic tyden, me na to stacily dve hodiny' :-) a tak jsem používal pouhou podmnožinu onoho mocného jazyka. To mi pripomelo jednu studii z predinternetovske ery, kdy jsme chteli nacpat do jednocipu to, cehoz mel plny kecky i normalni mikroprocesor. Ta studie se zabyvala dramatickym narustem nakladu s procentem vyuziti nejakeho systemu. Ted se mi k tomu nepovedlo nic vyhledat. Takze se nabizi otazka, zda je spravne snazit se vyuzit nejaky system na maximum ;) pf
Re: [Java] Program nejvýhodnější nabídky
Dne Mon, 08 Mar 2010 21:27:29 +0100 ghans-peter ghans-pe...@seznam.cz napsal/-a: Nejsem ještě pěvně rozhodnut jak to bude vypadat a jak to bude fungovat. Ale bylo by dobré aby ten program se dal spouštet u všech co chtějí navázat spojení a mají možnost změnit nabídku ve svůj prospěch. Není zcela jasné jak by to bylo u RMI. Já jsem viděl pouze aplikace přes příkazový řádek. No prave... A web jsi zrejme taky nevidel, o internetovem bankovnictvi jsi neslysel, ze? Aprioriry predjimas reseni, ktere by pripadalo v uvahu v dobach pred nastupem internetu tj. nekdy pred 20 lety. Vzhledem k tomu, ze ta aplikace nema krome vstupu od uzivatele a zobrazovani nejakeho stavu nic jineho delat, tak se mi jako jedine rozumne reseni jevi web, jak ti ostatne radi skoro vsichni i v sousedni konferenci, ale ty si meles svou, takze vlastne pevne rozhodnuty jsi ;-) V pripade potreby silnejsi ochrany pristupu nez je basic authentication by se pouzily certifikaty. pf
Re: SQLite
Dne Mon, 18 Jan 2010 17:22:05 +0100 Petr Jonas foxovic.vel...@seznam.cz napsal/-a: ano je to standalone aplikace, doufal jsem , jestli právě SqLite má něco podobného přímo implementováno v sobě, jinak budu muset si něco vymyslet. ;-) K SQLite existuje placene rozsireni, ktere sifruje na urovni file systemu viz http://www.hwaci.com/sw/sqlite/see.html Kdyz ho nebudes chtit koupit, tak si ho muzes napsat ;) HTH, pf
Re: Zkušenosti s Apache Wicket
Dne Sun, 29 Nov 2009 10:33:36 +0100 Marek ma...@gmail.com napsal/-a: Ktore odporucate(pripadne postupnost) ? Nasiel som jeden knizny zdroj Tapestry 5: Building application Step by step.(je to dobry zdroj? su v nej dobre vysvetlene principy..). V tomhle threadu jsem pro Wicket doporucoval knihu Enjoy Web Development with Wicket a tusim jsem se zminoval, ze stejny autor napsal podobnou knihu (necetl jsem) Enjoy Web development with Tapestry http://www.agileskills2.org/EWDT/index.html HTH, pf
Re: Zkušenosti s Apache Wicket
Dne Wed, 18 Nov 2009 13:54:42 +0100 Petr Zajíc p...@xzajic.cz napsal/-a: provedl určitý výběr . a vyšel mi z toho Apache Wicket. Má s ním někdo zkušenosti (dobré/špatné/proč?). Me taky. Tak jsem se ho sel ucit a zacali jsme v nem vetsi projekt. Zhruba se s tim pracuje, jak jsme ocekavali a kdyby v tom clovek delal tradicni web, tak s tim nejsou v podstate zadne problemy. Snad jedine, ze jsme puvodne jsme chteli zabrednout do EE bordelu co mozna nejmene, ale nakonec jsme skoncili s Mavenem a Spring-JPA-Hibernate. A meli jsme problemy s cestinou viz jiny thread v teto diskusi. Ale jakmile jsme zacali vytvaret slozitejsi stranky, tak jsme zacali narazet na vsech stranach - napr. kdyz chces udelat form, jehoz prvky budou rozestreny pres vice zavedes tam nejakou dedicnost stranek apod., tak s tim problemy zacnou. Komponentove Javu znám spíše z desktopu a komponentový přístup je mi blízký ;-)) Díky za případné postřehy, Petr
Re: Zkušenosti s Apache Wicket
Dne Wed, 18 Nov 2009 17:31:37 +0100 Petr Fejfar petr.fej...@seznam.cz napsal/-a: Sorry, uklep jsem se a omylem to odeslal nedokoncene... provedl určitý výběr . a vyšel mi z toho Apache Wicket. Má s ním někdo zkušenosti (dobré/špatné/proč?). Me taky. Tak jsem se ho sel ucit a zacali jsme v nem vetsi projekt. Zhruba se s tim pracuje, jak jsme ocekavali a kdyby v tom clovek delal tradicni web, tak s tim nejsou v podstate zadne problemy. Snad jedine, ze jsme puvodne chteli zabrednout do EE bordelu co mozna nejmene, ale nakonec jsme skoncili s Mavenem a Spring-JPA-Hibernate. A meli jsme problemy s cestinou, ktere mel na svedomi nejspis Maven viz jiny thread v teto diskusi. Ale jakmile jsme zacali vytvaret slozitejsi stranky, tak jsme zacali narazet na vsech stranach. Asi nejhorsi jsou ruzne JS komponenty do browseru (coz je obecny problem wicket/newicket) - v jednoduchych prikladech se zda, ze funguji, ale kdyz se pak z komponent vysklada stranka, tak je to k nepouziti :-( Uz jsem to taky nekde popisoval - mozna u sousedu na builderu a napr. do wicket fora jsem posilal tabulku s vysledky testu popup-menu v ruznych browserech - taky v podstate k nepouziti :-( Nektere komponenty napr. z jQuery jsme si museli zaintegrovat sami, ale k tomu, jak to udelat, je docela malo dokumentace. Na problemy si stezuji i grafici, kdyz ten logicky markup (coz je prednost wicketu) skladaji na stranku pomoci CSS. Taky se jim to ruzne ovlivnuje a v kazdem browseru jinak. Jinak to, ze v markupu jsou v podstate jen placeholdery a zbytek se dela v Jave, znamena vic prace pro Javisty. Taky je treba si uvedomit, ze rada veci je pomerne neintuitivni: napr. kdyz vis, ze pro zmenu stavu neceho ve strance potrebujes zmenit treba hodnotu atributu class, tak snad kazdy programator v kteremkoli jazyce by vedel, jak to udelat v nejakem sablonovacim systemu nebo pri primem zapisu do vystupu. Ale ve Wicketu musis pridat ke komponente instanci AttributeModifieru a vhodnym modelem zajistit, aby predana hodnota byla v dobe renderovani aktualni... Jak uz psal Robert Novotny - je treba hned od zacatku venovat zvysenou pozornost modelum a v praxi radsi vsude predavat modely, nez nechat komponenty, aby si samy predavane hodnoty ruzne cpaly do modelu. Jinak Wicket site a dokumentace mi prijde uboha a tzv. wicket-stuff, kde lze leccos spis okoukat nez rovnou pouzit, je IMHO jeden velkej bordel. Forum i IRC jsou mista, kde se lze zpravidla dobrat pomoci. Asi bych s tim nezacinal bez knih (kupoval jsem ebooky za rozumnou cenu u Manningu). Osobne bych doporucoval zacit Enjoy Web Development with Wicket (ta ma IMHO docela slusnou didaktickou uroven - autor snad psal neco podobneho pro Tapestry) a pak pokracovat Wicket in Action: v ni me sice rozcilovala udajne humorna forma, ale psali to autori Wicketu a obsahuje radu dulezitych informaci. HTH, pf
Re: Zkušenosti s Apache Wicket
Dne Wed, 18 Nov 2009 14:06:42 +0100 Robert Novotny robert.novo...@upjs.sk napsal/-a: Uciaca krivka je intenzivne strma a problem je v tom, ze v behu vidiet Tim myslis, ze se to da naucit rychle nebo ze se to uci pomalu? (viz treba http://en.wikipedia.org/wiki/Learning_curve The familiar expression steep learning curve may refer alternately to rapid learning that is easy, or especially hard, or to steady progress that is increasingly difficult [...] Originally it referred to quick progress in learning during the initial stages [...] Over time, a different use of the metaphor has become common, in which a steep learning curve means that something requires a great deal of effort to learn pf
Re: Zkušenosti s Apache Wicket
Dne Thu, 19 Nov 2009 00:18:49 +0100 Roman Zakutny roman.zaku...@gmail.com napsal/-a: ci existuju uz hotove zlozitejsie JS widgety (s priamou podporou AJAXu - modalne okna, taby, stromy). Bojim sa zlozitejsej integracie, nutnosti stylovania pre zachovanie dizajnu ako celku, atd... K tomu me napada jeste jedna poznamka ve vztahu k Wicketu: mame zkusenost, ze cim mensi ma clovek kontrolu nad vygenerovanym HTML kodem, tim je chovani/integrace JS widgetu problematictejsi... Napr. jsme se snazili vybirat jQuery widgety (puvodne jsme zkouseli YUI, ktere je nejvic do Wicketu integrovano, ale i DOJO a buhvi jak se ty dalsi shity jmenuji a nebylo to lepsi) pro 4 browsery: Firefox, MSIE, Opera, Chrome (razeno podle potizi) vzdy s velmi podobnym scenarem/vysledkem: 1. nasli jsme zhruba 80 variant widgetu 2. kdyz jsme prosli dema od autoru, tak nam jich zbylo tak 5 3. kdyz jsme udelali sample integraci do Wicketu, tak nam zbyly 1-2 4. Kdyz jsme to zaintegrovali do slozitejsi wicket aplikace, tak se nedalo pouzit NIC. IMHO je to dano tim, ze zalezitosti kolem webu se spis strikaji nez programuji, takze ten JS kod neumi poradne traversovat DOMem a u slozitych stranek poskladanych z komponent, kde se vystupni markup renderuje v podstate cely Wicketem, vychazeji docela kosate struktury, se kterymi si ty widgety neporadi. Zrejme jakmile to autorum tech widgetu nejak funguje v nekolika pripadech rucne napsaneho markupu, tak uz bezi strikat neco dalsiho a nikdy si nedaji praci, aby to napsali poradne a dostatecne obecne. Urcite nie je cielom si tieto veci znova programovat. Asi si dovedes predstavit, kolik casu nam vyse popsana procedura zabrala. Takze je otazka, zda jsme nemeli rovnou sednout a programovat ;-) Nakonec jsme skoncili tak, ze jsme slezli z hrusky a dost ubrali z predstav o bohatosti GUI s tim, ze jakmile to budeme mit funkcni, tak se vratime k nekolika kandidatum widgetu a zkusime je napsat poradne a vyrobit bohatsi verzi aplikace. Ale jsme sami sobe zakaznikem, takze nas nikdo nebuzeruje, ze tam chce mit to ci ono :-) HTH, pf
Re: Problemy s kodovanim cestiny
Dne Fri, 18 Sep 2009 10:59:46 +0200 Podlesak Kamil kamil.podle...@ips-ag.net napsal/-a: sekvenci, pokud se opravdu vsude nastavi spravne kodovani. Mozna je opravdu chyba v tom mavenu. Vypada to tak - kdyz jsem v retezcovych literalech pouzil escape sekvence, tak to funguje podle ocekavani, tzn. ze se v POMu *musi* nastavit project.build.sourceEncodingUTF-8/project.build.sourceEncoding a pak je to vsude sprave cesky. Takze jedine, ze by mel Maven jeste nejakou jinou volbu, ktera mi unikla... Nicmene, i tak porad hrozi nebezpeci ze prijmene noveho cloveka, on to otevre v nejakem editoru (IDE) kde si nezmenil nastaveni a buch - mate tam hromadu znaku ktere nedavaji zadny smysl v zadnem kodovani. V tom bych problem nevidel: - na zacatku dostane noty, jak si ma nastavit prostredi - kdyz neco zprasi, tak mu to commiter rejectne/revertne a at tu udela znovu - priste si to bude pamatovat Diky za pomoc, pf
Re: Zacatecnicky dotaz jak dostat do JPQL inner join on...
Dne Mon, 21 Sep 2009 17:11:15 +0200 Rastislav Siekel sie...@prosoft.sk napsal/-a: Znamena to, ze to bez doplneni stare tabulkyo vazbu @ManyToOne nejde? Presne tak. Tak jsem holt rezignoval a upravil i tu legacy DB a run-time engine, ktery nad ni jezdi, aby to vyhovovalo te Java persistenci :-((( Diky za pomoc, pf
Zacatecnicky dotaz jak dostat do JPQL inner join on...
Ahoj, potreboval bych postrcit, jak napsat JPQL: * mam entitu AppUser s 1:M asociaci na entitu Subscription (V PostgreSQL to udelalo vazebni tabulku) * mam entitu History a potreboval bych z History vybrat vsechny zaznamy pro daneho uzivatele s nejakou vlastnosti ze Subscription. V SQL bych napsal takhle: select h.xxx,h.yyy,... from history as h inner join subscription s on h.vlastnost=s.vlastnost inner join basalwebuser_subscription l on s.id=l.subscriptions_id inner join basalwebuser u on u.id=l.basalwebuser_id where u.id=? order by ... Pouzivam JPA+Hibernate. Jak mam dostat to ON h.vlastnost=s.vlastnost do JPQL? Diky, pf
Re: Zacatecnicky dotaz jak dostat do JPQL inner join on...
Dne Mon, 21 Sep 2009 09:45:16 +0200 Rastislav Siekel sie...@prosoft.sk napsal/-a: Ahoj, v JPQL neviem, ale pred týždňom sme tu niečo podobné riešili v Hibernate. Je to v manuáli v 14.3 - jedná sa o WITH clause v HQL. Nedari se mi. Pridal jsem do Subcsription jeste obracenou @ManyToOne asociaci user a sesmolil: select count(*) from History as hist inner join Subscription as subs with hist.vlastnost=subs.vlastnost inner join subs.user as user with user.id=? Na to HQL parser vyhazuje exception: Path expected for join! Dalsi varianta se stejnym vysledkem byla: select count(*) from History as hist inner join Subscription as subs with hist.vlastnost=subs.vlastnost and subs.user_id=? A neuspel jsem, ani kdyz jsem tomu primo zadal ten rano cistovany a odzkouseny SQL command - tam si stezuje pro zmenu JDBCExceptionReporter: Sloupec pojmenovaný id nebyl nalezen v ResultSet. Nevidi nekdo, co delam spatne? Diky, pf
Re: Zacatecnicky dotaz jak dostat do JPQL inner join on...
Dne Mon, 21 Sep 2009 16:10:04 +0200 Rastislav Siekel sie...@prosoft.sk napsal/-a: Presne tak, ako je urobená tá duhá väzba - ...join *subs.*user..., tak musí byť aj tá prvá. Takže nie ...join Subscription... ale ... join *hist.*Subscription Inak Hibernate nemá ako zistiť definíciu toho JOIN-u. No jo, ale ja zadnou hist.subscription nemam... hist je legacy tabulka plnena non-Java strojem a v Jave jsem ji jen napsal standalone entitu. A ted bych potreboval udelat nejaky jeji run-time join pres vazbu hist.vlastnost=subs.vlastnost, jako mi to funguje v obycejnem SQL Znamena to, ze to bez doplneni stare tabulky o vazbu @ManyToOne nejde? A proc mi nejde to odzkousene SQL te nenapada? Diky, pf
Re: Zacatecnicky dotaz jak dostat do JPQL inner join on...
Dne Mon, 21 Sep 2009 17:11:15 +0200 Rastislav Siekel sie...@prosoft.sk napsal/-a: Znamena to, ze to bez doplneni stare tabulky o vazbu @ManyToOne nejde? Presne tak. (Len pre istotu - nedopĺňaš väzbu do tabuľky, len do jej mapovania. Žiadna fyz. väzba tam byť nemusí.) No tak tomu prestavam rozumet: * puvodne jsem mel @OneToMany AppUser.subscription, coz fyzicky udelalo join table user_subscription s id zazanmu * kdyz jsem doplnil @ManyToOne Subscription.user abych mel obousmernou asociaci, tak mi to fyzicky pridalo foreign key do tabulky subscription, i kdyz by nemelo/nemuselo, protoze vse potrebne ma v te join table * kdyz jsem zkousel vnutit mu tu existujici join table jejim specifikovanim pomoci @JoinTable, tak hbm2ddl narazil na nejake FK constraints - nevim, co s tou tabulkou join table chtel udelat, tak jsem prozatim rezignoval a nechal tam ten FK. A proc mi nejde to odzkousene SQL te nenapada? To bude asi niečo triviálne - v mapovaní existuje h.id, ale v tom SELECT-e nie je v select-liste, alebo niečo podobné. To je mozne, ale nic takoveho nevidim. Vsude pouzivam kvalifikovane odkazy s aliasy tabulek a result set mam: sql.append(select h.*); P.S. Len na okraj - nemaž z mailu pôvodné texty - je to rýchlejšie ako pozerať sa do starých mailov, aký vlastne bol pôvodný SQL... :-) To slysim/ctu poprve - vetsinou se chce, aby se psalo bez nabodenicek a quotovalo. U toho bych zustal, ale priste tam ten SQL sam znovu zkopiruju. Diky, pf
Re: Zacatecnicky dotaz jak dostat do JPQL inner join on...
Dne Mon, 21 Sep 2009 17:32:02 +0200 Jan Dosoudil jan-k...@dosoudil.chr.cz napsal/-a: je nutné používat u obousměrných relací mappedBy=, v tabulce AppUser má být: @OneToMany(mappedBy=appUser) Subscription subscription; v Subscription: @ManyToOne AppUser appUser; Pokud se nepoužije mappedBy, vytvářejí se duplicitní vazby, které již existují. Tak jsem to takhle udelal a kdyz jsem dropnul DB a nechal ji znovu vytvorit, tak zrusil tu join table a do Subscription strcil FK, cili ted to vypada, jak kdybych si ten DDL delal rucne :-) Diky za pomoc, pf
Re: Problemy s kodovanim cestiny
Dne Wed, 16 Sep 2009 13:23:47 +0200 Martin Kuba ma...@ics.muni.cz napsal/-a: To nepomůže, servlet engine nečeká parametr charset, takže ho ignoruje. Ono to vypada, ze mi nepomuze vubec nic :'( Uz jsem z toho vazne gogo: vsechno mam v UTF8 a kdyz jsem ponastavoval i UTF8 ve Wicketu, tak mi to na webu zobrazuje cestinu spravne, ale zase jsem zjistil, ze mi nefunguje parser, volany ze sousedniho projektu, a to ani mimo web v obycejne konzolovce: - mam project A s frameworkem a v nem parser s regexem, ktery obsahuje znak pro stupen - mam obycejnou consolovou aplikaci jako project B, kteremu reknu, ze je zavisly na projektu A. V metode main() nadefinuju string taky se znakem pro stupen a zavolam parser z projektu A. - vsechno je v UTF8, projekty jsou Maven managed, parent POM obou projektu ma property project.build.sourceEncodingUTF-8/project.build.sourceEncoding - spustim main() a parser nefunguje. Kdyz trasuju do Pattern.compile(), tak mi Eclipse ve stringu predavanem do compile() zobrazuje pred tim stupnem navic nejaky velky A s nabodenickem (uz si nepamatuju co to presne bylo), cili ten Maven tam prelozi buhvi co. - Kdyz v parent POMu vyhodim to sourceEncoding a necham to by default, tak to funguje, ale zase mi TomCat mrsi cestinu :-( -- Jaka je spravna cesta z toho ven, aby ta cestina fungovala vsude a bez problemu? Diky za kazdou pomoc, pf
Re: Problemy s kodovanim cestiny
Dne Thu, 17 Sep 2009 19:02:17 +0200 Podlesak Kamil kamil.podle...@ips-ag.net napsal/-a: Jiz jsem to jednou psal, ale napisu to znova: zdrojove kody v Jave piste zasadne v ASCII. Jestli mi neco neuniklo, tak jsi mi psal, ze mam-li non-ASCII obsah, nesmim pouzivat GET... Pokud uz tam chcete dat nejaky exoticky znak, tak JEDINE pres \u Hmmm... Ale tady http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5 Dodrzovani tohoto pravidla usetri hodne boleni hlavy.
Re: Problemy s kodovanim cestiny
asddsdadsdasdasdasdasdasdDne Thu, 17 Sep 2009 19:02:17 +0200 Podlesak Kamil kamil.podle...@ips-ag.net napsal/-a: Jiz jsem to jednou psal, ale napisu to znova: zdrojove kody v Jave piste zasadne v ASCII. Jestli mi neco neuniklo, tak jsi mi psal, ze mam-li non-ASCII obsah, nesmim pouzivat GET... Pokud uz tam chcete dat nejaky exoticky znak, tak JEDINE pres \u Hmmm... no to by me ani ve snu nenapadlo, ze ve 21. stoleti existuje prostredi, kde je nutne znak, ktery lze napsat na klavesnici a korektne zobrazit na obrazovce, zejmena kdyz prostredi predstira, ze je Unicode awared, zadavat jak pred 30 lety escape sekvenci. (Ale asi melo, kdyz v .properties lze pres veskery pokrok v IT zadavat stale jen Latin-1...) Alespon v JLS pisou (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5), ze *Characters may be represented by escape sequences* :-OOO Ne ze musi... Kdo ten bordel dela? Maven? Nebo to vadi samotnemu jazyku? Dodrzovani tohoto pravidla usetri hodne boleni hlavy. Diky za radu - zkusime to prepsat a pretestovat cely ten deploy retezec, jestli ta cestine zacne konecne fungovat. Diky, pf
Problemy s kodovanim cestiny
Ahoj, mohl by mi nekdo poradit, co musim kde nastavit, aby mi spravne fungovala cestina? 1. Mam ceska WXP, Wicket projekty, ktere maji vsechny soubory (.JAVA, .HTML, .XML) v UTF-8. Texty pro lokalizaci mam v .XML, ne v .properties, abych se vyhnul Latin-1. Kdyz to spoustim v JEE Eclipse at uz pres Jetty nebo pres TomCat, tak naprosto vse funguje spravne. 2. V parent POMu mam v properties nastaveno project.build.sourceEncodingUTF-8/project.build.sourceEncoding a kdyz Mavenem vytvorim .war s strcim ho Tomcatu na stejnem stroji, cestina je v haji, ovsem ne cela: lokalizovane texty, ktere taham z .XML jsou spravne, ale spatne jsou staticke texty z .HTML souboru. 3. Kdyz .war strcim Tomcatu na Linuxu, tak tam je cestina skoro spravne, tj. staticke texty i lokalizovane texty jsou spravne, ale problemy jsou s kodovanim dat zadavanych do editu ve formulari (napr. znak pro stupen) 4. Kdyz v POMu zrusim to UTF-8, tak se u me na localhost nic nezmeni tj. TomCat mrsi cestinu stejne jako predtim, ale na Linuxu, kde to skoro fungovalo, to zacne mrsit obsahy comboboxu, ktere se plni hodnotami primo z .JAVA kodu. Diky, pf
Re: Problemy s kodovanim cestiny
Dne Wed, 16 Sep 2009 09:35:41 +0200 Podlesak Kamil kamil.podle...@ips-ag.net napsal/-a: Ve všech sevletech musí být vždy nastaveno správné kódování jak v requestu, tak v odpovědi. javax.servlet.ServletRequest#setCharacterEncoding javax.servlet.ServletResponse#setContentType + javax.servlet.ServletResponse#setCharacterEncoding Ve Wicketu je treba zavolat u overridnute metody init() v aplikaci: getMarkupSettings().setDefaultMarkupEncoding(UTF-8); getRequestCycleSettings().setResponseRequestEncoding(UTF-8); Pak se mi opravi cestina ve statickych textech ctenych z .HTML sablon. Ale pro zmenu to zmrsi cestinu v dorp-dow choice seznamu, kde jsou ty stringy zapsany v Java kodu, ktery je pres IChoiceRenderer vyrenderuje do vystupniho kodu. Pricemz kod toho .JAVA dokumentu je urcite UTF-8 Pokud máte formulář kde se může vyskytnout něco jiného než ASCII, nikdy nepoužívejte GET. Data jsou urcite POSTovana Diky, pf
Re: Problemy s kodovanim cestiny
Dne Wed, 16 Sep 2009 09:35:47 +0200 Martin Kuba ma...@ics.muni.cz napsal/-a: Data z formuláře jsou speciální případ, je nutné zajistit, aby HTTP hlavička Content-Type strány s formulářem obsahovala parametr charset=utf-8. Nevím jak se to nastavuje u Wicketu, ale nakonec se musí zavolat metoda HttpServletResponse.setContentType(). Jestli myslis http-equiv=Content-Type, tak ten ma hodnotu UTF-8. Nastavujeme ho v abstraktnim predkovi vsech nasich stranek a primo v markupu: meta http-equiv=Content-Type content=text/html; charset=utf-8/ Diky, pf
Re: Hibernate modelar
Dne Thu, 30 Jul 2009 10:19:58 +0200 Lukas Barton lu...@cnawr.cz napsal/-a: http://www.andromda.org/ my melo umet vygenerovat Java i Hibernati mapping z UML. Nepamatujes si, jestli to umelo dedicnost entit? Takze ja osobne mapovani, schema i Java radeji pisu rucne. (casto schema dela DB expert a nikoliv developer), My to mimo svet Javy delame tak, ze jsme si kdysi koupili CaseStudio, kde se to navrhne a vygeneruje se DDL. Ten pak zchroustame nasimi scripty napsanymi v Pythonu, ktere vygeneruji stuby pro pouzivanou platformu. Ovsem trpi to tim, ze to nema model migration/evolution - o to jsme se pokouseli napr. ve spojeni s Django-evolution, ale tenkrat bohuzel ve spojeni s MySQL neuspesne. Nakonec to zrejme dopadne tak, ze to navrhneme zase v CaseStudiu a rucne prepiseme. A kdyz mezitim nenajdeme nic jineho, tak mozna vyprasime i nejake quickdirty scripty, kterymi to vygenerujeme. pf
OT: Re: Hibernate modelar
Dne Thu, 30 Jul 2009 13:25:28 +0200 Ladislav Thon ladi...@gmail.com napsal/-a: JavaScriptu, takže máš přístup přímo k modelu a nemusíš se prasit se zpracováním SQL. Ach, kde jsou ty časy :-) To mas pravdu, ale DDL je znamy a jasny, zatimco pokud si matne vzpominam, tak nam tak scriptovani v CaseStudiu nepripadalo... Mozna se mrknu, jak to s tim ted vypada v Ropuse, na kterou to prejmenovali viz http://www.casestudio.com/enu/default.aspx pf
Re: MMS
Dne Tue, 14 Jul 2009 13:17:58 +0200 Tomas Hubalek tomas.huba...@onsemi.com napsal/-a: Pokud si dobre vzpominam, tak na dumb telefonech prijde obycejna SMS s web adresou, kde si MMS vyzvednout na webu. V pripade, ze ME neni MMS awared, tak se na nej posila WAP Push, coz lze chapat jako *specialni* SMS. Ale ne kazdy operator poskytuje rozhrani, aby se Wap Push dal na ME poslat. Pravda, jak to vypada v pripade, ze by bylo ME opravdu dumb nevim, protoze takova uz snad ani nejsou... pf
Re: BPEL, SOA, CASA
Dne Fri, 19 Jun 2009 09:32:40 +0200 Michal Karták michalkar...@gmail.com napsal/-a: Diky za tip. a nejake online zdroje? Skoro on-line: po zaplaceni kartou v podstate hned ke stazeni ;-) Nedavno jsem zakopnul (necetl jsem) o: - http://manning.com/davis/ - http://www.manning.com/kanneganti/ - http://www.manning.com/rotem/
Re: Aplikace sklad - vhodna databaze, framework?
URBAN Leos wrote: embedded = vložený (embed = vložit, zapustit) Osobne bych se dal prednost pojmum vestaveny, zabudovany pf
Re: Aplikace sklad - vhodna databaze, framework?
Kouba Tomas wrote: nevim, zda nejsme trochu off-topic, ale mozna prave to, ze Oracle InnoDB koupil je spise dukazem toho, ze MySQL je velmi kvalitni databaze, ne? :-) Schvalne jsem vystrachal kus prispevku z roku 2001 v comp.databases, kde Heikki Tuuri vysvetluje, proc implementoval InnoDB do MySQL a ne do PostrgreSQL: The first reason was that in MySQL there is a standardized interface to lower level storage managers (called table handlers in MySQL) which MyISAM, BDB, and InnoDB use. I have not studied PostgreSQL source at that detail, but the object-relational features there may require something extra from the storage manager. Another reason is speed: InnoDB was designed to be the fastest disk-based database engine in the world. Also MySQL SQL interpreter is fast. The combination MySQL/InnoDB is thus only 30 % slower than a standalone InnoDB and in many tests faster than the standard table type of MySQL. [...] The third reason was that Monty Widenius, the writer of MySQL lives in the same town as I :). Muj povrchni odhad je , ze vice jak polovina web aplikaci pouziva MySQL. To je snad take dukaz neceho... A dival ses nekdy, jake verze MySQL napr. ISP provozuji a s jakym enginem? Vetsinou jsou to verze 4.1 s MyISAM... pf
Dostupnost prekladace Ada (was: Programator roku 2006)
Martin Kuba wrote: synchronized) jsem pred Javou videl jenom v jazyku Ada, a v te dobe (pred Javou) mel prekladace Ady pouze Pentagon. Uz si to moc nepamatuju, ale oblast vazneho programovani jsem opustil v polovine roku 94 a do te doby nebylo o Jave ani vidu ani slechu. A neni divu, protoze podle Wikipedie byla v te dobe teprve prejmenovana z OAK na JAVA a oficialne predstavena na konferenci az v kvetnu 95. Ale prekladac ADA uz jsme tenkrat par let meli a zacali jsme ho v nekterych projektech pouzivat. Dokonce bych rekl, ze to bylo nekdy kolem roku 89, protoze na konci 90 byly zastaveny vsechny ukoly RVT a podnik zacal hledat zahranicni instrumentaci. A jestli me pamet neklame, tak jsme ho ziskali pri spolupraci s CVUT v Plzni. pf
Re: Java MySQL UTF8
Burdik Petr wrote: databaze. Ale vyvazuje to vysokym vykonem a zdarma. MySQL neni pro komercni ucely zdarma, viz http://www.mysql.com/company/legal/licensing/ pf
Re: SMS gateway for GSM networks II
Štefan Novák wrote: Urcite takyto problem uz niekto riesil. Resil. V podstate vsechno co potrebujes jsme pred lety vyvinuli a bezi to v rade zemi a cas od casu do toho neco dodelame. Ovsem ne v Jave. Jelikoz se objevila urcita poptavka na portovani naseho systemu do Javy, tak o tom samozrejme uvazuje, ovsem jen na komercni bazi. Mozna by se dalo uvazovat o nejake spolupraci. Ale na zitra ten port neplanujeme... pf
