Re: O/R mapování a Torque
To ze je Hibernate svazany s EJB je nesmysl. Hibernate 3.0 umoznuje pouze to, ze muze byt take pouzit jako EJB 3.0 kompatibilni implementace. Je ciste na vas jestli pouzijete Hibernate klasickym zpusobem a nebo pouzijete jeho EJB 3.0 API (EntityManager). Tomáš Procházka napsal(a): Zdravím. Ptal jsem se v oficiální konferenci Torque, proč jej preferují před Hibernate a dostal jsem tuto odpověď od Greg Monroe Greg.Monroe at DukeCE.com I took a quick look at Hibernate a while back and came away with the impression that it is strongly tied to the complexity of Enterprise Java Beans. It simplifies EJB operations but still requires a lot of manual bookkeeping and coding to get started. So, IMHO, Torque was better because it lets you go from laying out the tables to using code much faster. Torque's tools also help support and speed up a lot of the processes needed to go from development to delivery and then maintaining the application. Things like: Having an easily produced common file that describes and documents your application's data storage schema. (Makes version comparison a simple matter of comparing XML file versions.) It makes the generation of the SQL scripts to create the DB schema for your application a snap, regardless of which vendor you are using. Ease of implimenting changes to tables into your code. Just change the xml schema and rebuild. Ease (but not enforcement) of creating cross DB Server engine code, so you're application is not tied to a single vendor's implimentation. Others with more hibernate experience might have different opions. But I'd say if you don't need EJB support, don't use Hibernate. And FWIW, IMHO, after working with a major EJB application for 5+ years and then developing it's replacement with Torque, EJB is overkill for most common applications which really don't need 100%, never loose a transaction due to acts of god. A good clustered Servlet only environment can give you 99.9+% reliablility without all of EJB's overhead (which is a real response killer with all it's open sockets between this and that..) Oh, and as to performance, one thing that Torque does well is to supply a nice easy to configure/use connection caching methodogy. This is a big performance gain for any OM layer since a large part of SQL transaction overhead is simply establishing the connections to the DB. You should look at what other OM layers do in this regard if you are concerned about response time performance. -- S pozdravem Roman Dagi Pichlik /* http://www.sweb.cz/pichlik/ Blog pro kodery */ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Spring MVC a co na view vrstvu
Dik. Uvazoval jsem o tom, ale nevim jestli je to dost stabilni. Taky se mi zda ze k tomu je bidne dokumentace. Co ostatni? Pouzivate Spring MVC? A jak? S Velocity? nebo mate nejake svoje JSP tagy? Tom Michal Palička napsal(a): Dobry den, podivejte se na Spring 2.0. Zatim sice jeste neni v ostre verzi, ale udajne se k ni jiz blizi... Nova verze by mela obsahovat JSP tagy pro ovladaci prvky formularu. mp. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomas Hubalek Sent: Thursday, April 20, 2006 3:07 PM To: Java Subject: Spring MVC a co na view vrstvu Zdar, rozhodl jsem se vyzkouset MVC z Spring 1.2 celkem s tim nemam problem, ale chybi mi takove ty html:form, html:input tagy ze struts. Co pouzivate na view vrstvu? Nejsem si jisty, jestli chci ji napr. do Velocity nebo to FreeMarkeru, protoze jsem se uz celkem naucil JSTL i EL i JSP Tags 2.0, takze myslim ze ucit se Velocity je pro me neuzitecne. Muzu se mylit. Poucte me... ;-) Dik Tom
Re: O/R mapování a Torque
Par pripominek na toto tema. Pro upresneni s Hibernate verze 2.x delam vice nez 3 roky, verzi 3 jsem jeste nepouzil, Torque take ne. Hibernate jsem tenkrat vybral po vyhodnoceni vice nastroju (OJB, Castor, Cayene, DODS), tenkrat se o nem jeste nikde moc nepsalo, Torque mezi vyhodnocovanymi nastroji nebyl. Tomáš Procházka napsal(a): Zdravím. Ptal jsem se v oficiální konferenci Torque, proč jej preferují před Hibernate a dostal jsem tuto odpověď od Greg Monroe Greg.Monroe at DukeCE.com I took a quick look at Hibernate a while back and came away with the impression that it is strongly tied to the complexity of Enterprise Java Beans. It simplifies EJB operations but still requires a lot of manual bookkeeping and coding to get started. Hibernate neni podle me svazan s EJB vubec, vznikl nezavisle jako znacne jednodussi a presto feature rich verze OR nastroje oproti EJB entity beanum pred verzi EJB3. Prave pro tuto jednoduchost a pouzitelnost se tvurci specifikace EJB3 (ktera je uplne nova, je nyni ve fazi dokoncovani) inspirovali u Hibernate 2.x a take pote vznikl Hibernate 3 ktery muze slouzit jako zaklad pro implementaci EJB3 (jak ho pouziva JBoss a rekl bych ze se na to chysta i BEA ve WebLogicu). Zda se mi ze Greg tuto historii prilis nezna. Vubec celkem mnoho lidi si jednu dobu myslelo ze EJB3=Hibernate a naopak coz samozrejme neni pravda. So, IMHO, Torque was better because it lets you go from laying out the tables to using code much faster. Torque's tools also help support and speed up a lot of the processes needed to go from development to delivery and then maintaining the application. Things like: Having an easily produced common file that describes and documents your application's data storage schema. (Makes version comparison a simple matter of comparing XML file versions.) Mapovani pro Hibernate je take v XML souborech, u Hibernate 3 lze pouzit i anotace ala EJB 3 cehoz ja osobne ale nejsem tak uplne fanda. It makes the generation of the SQL scripts to create the DB schema for your application a snap, regardless of which vendor you are using. Generovat SQL script umi Hibernate take. Ale jak uz zde nekdo psal, stejne je vzdy potreba DB schema doplnit o dalsi veci kvuli vyladeni atp. Ja jsem vetsinou postupoval tak, ze udelam JavaBeany pro persistenci (diky Eclipse jde gettery, settery generovat), pote pomoci Hibernatoru (Eclipse plugin) vygeneruji zaklad XML mapovacich souboru a ty pote doladim rucne a pote z nich generuji SQL DDL ktere pak rucne doplnim o specificke indexy atp. Takto to generuji na zacatku, dalsi mensi zmeny pak jiz vetsinou delam kompletne rucne aby se zachovala rucni prace kterou jsem v jednotlivych krocich drive pouzil. Hibernate ma i nastroje pro jine postupy, napr. od DB schematu k XML a k objektum, ty ale moc neznam a nevim nakolik jsou nebo nejsou dobre. Podle me ale stejne nastroje nemohou zvladnout vse automaticky optimalne, stejne do toho musite zasahovat rucne protoze OR mapovani neni uplne jednoznacny proces a nektere veci jde delat ruzne pricemz v nekterych situacich je vhodne pouzit jiny pristup nez v jinych. Ease of implimenting changes to tables into your code. Just change the xml schema and rebuild. To umi torque generovat i zmenove SQL DDL scripty? Pokud ano tak klobouk dolu uz vzhledem k nekompatibilite databazi u prikazu typu alter table ;-) Pri zmenach DB schematu u existujici aplikace je take casto treba napsat scripty pro upravu existujicich dat atp. coz je stejne rucni prace. Ease (but not enforcement) of creating cross DB Server engine code, so you're application is not tied to a single vendor's implimentation. U Hibernate toto podle me take neni problem. Others with more hibernate experience might have different opions. But I'd say if you don't need EJB support, don't use Hibernate. Hibernate jsem zacal pouzivat prave proto abych nemusel pouzivat EJB Entity Beany. And FWIW, IMHO, after working with a major EJB application for 5+ years and then developing it's replacement with Torque, EJB is overkill for most common applications which really don't need 100%, never loose a transaction due to acts of god. A good clustered Servlet only environment can give you 99.9+% reliablility without all of EJB's overhead (which is a real response killer with all it's open sockets between this and that..) Souhlas, presne proto jsem zacal pouzivat Hibernate. EJB ma podle me opodstatneni v urcitych situacich, predevsim pro vzdaleny pristup ke sdilene business logice (at uz standardne pomoci RMI nebo dnes pomoci ruznych WebServices related standardu). Oh, and as to performance, one thing that Torque does well is to supply a nice easy to configure/use connection caching methodogy. This is a big performance gain for any OM layer since a large part of SQL transaction overhead is simply establishing the connections to the DB. You should look at what other OM layers do in this regard if you are
migrace na tomcat 5.5, jstl a el tags
Ahojte,
premigroval jsem na vyvojovem notebooku na tomcat 5.5. Vsechny
souvisejici problemy s knihovnami, rekonfiguracemi, ... mam za sebou
krome jednoho problemu.
Nemuzu pouzivat nasledujici konstrukci:
c:out value='${nejakahodnota}' /
Pise mi to ze:
According to TLD or attribute directive in tag file, attribute value does not
accept any expressions
Je mi jasne co mi pise, ale moc si nevim rady jak z teto slamastiky ven.
Pet
Re: migrace na tomcat 5.5, jstl a el tags
On Friday 21 April 2006 13:16, Burdik Petr wrote:
Ahojte,
premigroval jsem na vyvojovem notebooku na tomcat 5.5. Vsechny
souvisejici problemy s knihovnami, rekonfiguracemi, ... mam za sebou
krome jednoho problemu.
Nemuzu pouzivat nasledujici konstrukci:
c:out value='${nejakahodnota}' /
Pise mi to ze:
According to TLD or attribute directive in tag file, attribute value does
not accept any expressions
Je mi jasne co mi pise, ale moc si nevim rady jak z teto slamastiky ven.
Nevim, je to divne, takze strelba od boku: neni treba zmena v JSTL takova, ze
c:out${nejakahodnota}/c:out?
Co rika c.tld? Neni zavedeny novy attribut expression? Vazne nevim...
--
Oto 'tapik' Buchta, [EMAIL PROTECTED]
http://www.buchtovi.cz
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
Re: migrace na tomcat 5.5, jstl a el tags
S tim ted valci hlavne nasi studenti v jednom predmetu. Problem je v
tom, ze se mezi sebou perou knihovny pro JSTL.
Pokud pouzili JSTL library 1.1 z Netbeans, tak nesmeli mit ve WEB-INF
vlastni TLD soubory ani v lib soubory jstl.jar a standard.jar.
Nevim proc ale v tech jarech co jsou v Netbeans to zahadne chape El
vyrazy jako runtime expression a tak se musi pouzit jako uri
core-rt.tld. ktere ma nastaveny priznak rtexpr v TLD souboru na true.
Lumi(r)
Burdik Petr wrote:
Ahojte,
premigroval jsem na vyvojovem notebooku na tomcat 5.5. Vsechny
souvisejici problemy s knihovnami, rekonfiguracemi, ... mam za sebou
krome jednoho problemu.
Nemuzu pouzivat nasledujici konstrukci:
c:out value='${nejakahodnota}' /
Pise mi to ze:
According to TLD or attribute directive in tag file, attribute value
does not accept any expressions
Je mi jasne co mi pise, ale moc si nevim rady jak z teto slamastiky ven.
Pet
Re: migrace na tomcat 5.5, jstl a el tags
Ahojte,
pouzivam sice netbeans, ale tam problem nemam. Pouzivam standard.jar a
jstl.jar ze springu, ktere jsou tam pribaleny.
relavantni radky z /WEB-INF/lib/c.tld
attribute
namevalue/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
Jeste pro poradek udavam knihovny a verze:
jstl.jar - 1.0.3
standard.jar - 1.0.6
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
Je to presne tim co pise Lumir. Diky. Stacilo prehodit na _rt a je to ok.
Pet
Lumír Návrat wrote:
S tim ted valci hlavne nasi studenti v jednom predmetu. Problem je v
tom, ze se mezi sebou perou knihovny pro JSTL.
Pokud pouzili JSTL library 1.1 z Netbeans, tak nesmeli mit ve WEB-INF
vlastni TLD soubory ani v lib soubory jstl.jar a standard.jar.
Nevim proc ale v tech jarech co jsou v Netbeans to zahadne chape El
vyrazy jako runtime expression a tak se musi pouzit jako uri
core-rt.tld. ktere ma nastaveny priznak rtexpr v TLD souboru na true.
Lumi(r)
Burdik Petr wrote:
Ahojte,
premigroval jsem na vyvojovem notebooku na tomcat 5.5. Vsechny
souvisejici problemy s knihovnami, rekonfiguracemi, ... mam za sebou
krome jednoho problemu.
Nemuzu pouzivat nasledujici konstrukci:
c:out value='${nejakahodnota}' /
Pise mi to ze:
According to TLD or attribute directive in tag file, attribute value
does not accept any expressions
Je mi jasne co mi pise, ale moc si nevim rady jak z teto slamastiky ven.
Pet
Re: algoritmus na rozdil stringu
Stanislav Ošmera napsal(a): Ahoj, Potreboval bych dobrej a hodne rychlej algoritmus ktery porovna dva stringy a vyhodi mi cislo jak hodne jsou rozdilny. Kdyz jsou stejny tak 0, kdyz jsou si hodne podobny tak maly cisloatd. Treba ceska pojistovna as. a ceska pojistovna jsou si hodne podobny. Rozdil muze byt kdekoliv ve stringu takze nelze pocitat kolik pozic je stejnych. Podobny stringy jsou i ty s nejakym preklepem ceska pojisotonva as. Nedari se mi nic vhodneho nalezt ani vymyslet a kdyz neco tak to ma exponencialni slozitost a je to pomaly. Jo jde mi o obecnej algoritmus takze java v tom nehraje roli. Diky za pomoc. Hezky o tom pise clanek http://www.english.upenn.edu/~jlynch/Computing/compare.html Jinak preji prijemnou zabavu pri implementaci. :-)
Re: migrace na tomcat 5.5, jstl a el tags - zajimavutka
Ahojte,
prave jsem upgradoval na jstl.jar (1.1.2) a standard.jar (1.1.2) a
vsechno jede v pohode. Jenom je potreba v header stranek uvadet misto:
%@ taglib prefix=c uri=http://java.sun.com/jsp/core; %
toto:
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
Pak si clovek pomuze i bez toho rt. Preju vsem moc pekny den a moc diky.
Moc mi Vase pomoc pomohla. To je veta jak z nosu :)
Pet
Burdik Petr wrote:
Ahojte,
pouzivam sice netbeans, ale tam problem nemam. Pouzivam standard.jar a
jstl.jar ze springu, ktere jsou tam pribaleny.
relavantni radky z /WEB-INF/lib/c.tld
attribute
namevalue/name
requiredtrue/required
rtexprvaluetrue/rtexprvalue
/attribute
Jeste pro poradek udavam knihovny a verze:
jstl.jar - 1.0.3
standard.jar - 1.0.6
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
Je to presne tim co pise Lumir. Diky. Stacilo prehodit na _rt a je to ok.
Pet
Lumír Návrat wrote:
S tim ted valci hlavne nasi studenti v jednom predmetu. Problem je v
tom, ze se mezi sebou perou knihovny pro JSTL.
Pokud pouzili JSTL library 1.1 z Netbeans, tak nesmeli mit ve WEB-INF
vlastni TLD soubory ani v lib soubory jstl.jar a standard.jar.
Nevim proc ale v tech jarech co jsou v Netbeans to zahadne chape El
vyrazy jako runtime expression a tak se musi pouzit jako uri
core-rt.tld. ktere ma nastaveny priznak rtexpr v TLD souboru na true.
Lumi(r)
Burdik Petr wrote:
Ahojte,
premigroval jsem na vyvojovem notebooku na tomcat 5.5. Vsechny
souvisejici problemy s knihovnami, rekonfiguracemi, ... mam za sebou
krome jednoho problemu.
Nemuzu pouzivat nasledujici konstrukci:
c:out value='${nejakahodnota}' /
Pise mi to ze:
According to TLD or attribute directive in tag file, attribute value
does not accept any expressions
Je mi jasne co mi pise, ale moc si nevim rady jak z teto slamastiky
ven.
Pet
Re: migrace na tomcat 5.5, jstl a el tags
Burdik Petr wrote: Ahojte, pouzivam sice netbeans, ale tam problem nemam. Pouzivam standard.jar a jstl.jar ze springu, ktere jsou tam pribaleny. relavantni radky z /WEB-INF/lib/c.tld attribute namevalue/name requiredtrue/required rtexprvaluetrue/rtexprvalue /attribute Jeste pro poradek udavam knihovny a verze: jstl.jar - 1.0.3 standard.jar - 1.0.6 ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 Je to presne tim co pise Lumir. Diky. Stacilo prehodit na _rt a je to ok. Jo, TomCat 5.5 je implementace Servlet2.4/JSP2.0, ke kterym patri JSTL 1.1. Kdyz pouzijete JSTL 1.0, ktere jsou delane pro Servlet2.3/JSP1.2 (Tomcat 4.1), tak musite pouzit prave _rt verze. U JSP2.0 se totiz na EL vyrazy vrhne uz samotne JSP, a do tagu tak predava uz objekt odpovidajici vyrazu. Kdezto v JSP1.2 se EL vyrazy dostaly az do tagu, protoze pro JSP to byl nevyznamny staticky text. Pokud muzete, upgradujte na JSTL 1.1. Makub -- ~~ Supercomputing Center Brno Martin Kuba Institute of Computer Scienceemail: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 -- smime.p7s Description: S/MIME Cryptographic Signature
RE: algoritmus na rozdil stringu
Jde o problém výpočtu Levenshteinovy vzdálenosti, možná Vám pomůže některý z těchto odkazů :-) http://www.google.com/search?hl=csq=levenshtein+distancebtnG=Hledatlr = Tomáš Záluský -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislav Ošmera Sent: Friday, April 21, 2006 2:04 PM To: konference@java.cz Subject: algoritmus na rozdil stringu Ahoj, Potreboval bych dobrej a hodne rychlej algoritmus ktery porovna dva stringy a vyhodi mi cislo jak hodne jsou rozdilny. Kdyz jsou stejny tak 0, kdyz jsou si hodne podobny tak maly cisloatd. Treba ceska pojistovna as. a ceska pojistovna jsou si hodne podobny. Rozdil muze byt kdekoliv ve stringu takze nelze pocitat kolik pozic je stejnych. Podobny stringy jsou i ty s nejakym preklepem ceska pojisotonva as. Nedari se mi nic vhodneho nalezt ani vymyslet a kdyz neco tak to ma exponencialni slozitost a je to pomaly. Jo jde mi o obecnej algoritmus takze java v tom nehraje roli. Diky za pomoc. -- Stanislav Ošmera Work: +44 (0)2075 980 348 Cell: +44 (0)7914 635 412 private email: [EMAIL PROTECTED] work email: [EMAIL PROTECTED] Skype: sosmera ICQ:149634231
umisteni JFrame
shoj potreboval bych otevirat formular na stejnem miste jako se otevre popup menu z ktereho ho oteviram. posilam si jako parent JmenuItem ze ktereho ho to poustim ale bohuzel se mi nedari. jak tohle resite? Diky moc Ales
