Web framework kiválasztás

Java

Hello,

Az igazsághoz mindig több út vezet. Én próbálom a legrövidebbet megtalálni :). Összegyűjtöttem néhány számomra fontos vezérlő elvet, amit az áhított megoldásnak (framework) teljesíteni kellene.

- MVC modell megvalósítható vele (nem gányolás útján)
- Hatékonyan használható, könnyen tanulható
- Széles körben használt, szabványos
- Az alkalmazás adatbázis függetlensége megvalósítható vele (ez nem biztos h fw kérdése)

A leendő alkalmazásról néhány gondolat:

- Adatfeldolgozás orientált (kevés adatfelvitel, sok lekérdezés)
- user,group,acl szintű jogosultságkezelés (JAAS?)
- Viszonylag kis felhasználószám (10-1500)
- Fontos lehet az alkalmazás elkülöníthetősége (profil ?) (pl. két különböző felhasználói csoport ua. az app-ot használja más db-vel)
- Legyen jól skálázható

Nice to have:

- Formok definiálási lehetősége pl. xml-ből (az oldalon X csoportnak X formot mutatom és validálom, Y-nak Y formot.)
- Riportolásra valami jó kis tool (JasperReports ?)
- Lehetőleg problémamentesen cserélhető legyen a DB backend, ha szükséges
- Külső rendszerkapcsolatok (pl.web service) lehetősége

Első sorban egy iránymutatásra lennék kíváncsi, ki milyen eszközrendszerrel állna neki a feladatnak (milyen alkalmazásszerver, IDE, web framework stb.) és miért pont azzal stb.
(Nyilván vannak erősen szubjektív szempontok).

Köszönöm előre is!

update:

Fontos h java legyen :)

update2:

Gyűlik az info szépen, köszönöm az eddigieket. Az még érdekelne, hogy pl. a mit nyerhetek alkalmazás szerverek terén egy container-el szemben (glassfish vs. tomcat vagy jetty ? Kell e ez nekem a vázolt feladathoz ?)
Köszi.

update3:
Most modellezem a különféle megoldásokat. Kerestem a Netbeans-ben a Visual Editor-t, de szépen kivették belőle :(. A 6.5.1-ben van meg utoljára. Tudom, a design legyen a designerek dolga, azok meg ne matassanak a nb-ben, de azért mégis.. A jelenlegi 6.9-ben nyoma sincs. Szóval elkeserítő picit a helyzet ebből a szempontból.
Ki, hogy oldja meg ezt a kérdést ? (Külön tool-t használ (pl. DW), kézzel rakja össze az oldalt stb.)
Köszi.

update4:
Az UML modellező plugin sem része már a Netbeans-nek (6.7-ig benne volt)
Jöhetnek az alternatívák UML modellezésre. (tudom, ne használjak nb-t).

update5:
Végül, de szerintem nem utoljára a fejlesztői környezetről, infrastruktúráról szeretnék begyűjteni minél több információt.
A következők a tervek:
- A fejlesztők localhost-on fejlesztenek, tesztelnek elsődlegesen (SVN, közös Maven repo)
- Lenne egy teszt szerver, ahova időnként deploy-olnánk a kész cuccot.
(Itt lenne a részletes teszt, mielőtt élesbe kerül a rendszer.)
- Harmadik lépcsőként jöhetne az éles rendszer
Érdekelne pl. a projekten belüli csomagok (Business Logic, DAO stb. mit és hogyan érdemes csomagolni) vagy akár az SVN repo célszerű felépítése.
Köszi.
update6:
DI (Dependency Injection) miért jó nekem ?

  • 10194 megtekintés

( uid_194 | 2011. 01. 19., sze – 22:16 )

Fontos, hogy Java legyen? O:)

Mer' ha nem, akkor Django. A teljesitendo kovetelmenyeknek mind megfelel, user kezeles beepitve (es bovitheto), egyszeruen megoldhato hogy egyik instanceban X legyen a config, mashol Y. Akar magan appon belul is megoldhato, hogy egyik esetben egyik db-t hasznalja, masikban masikat.

DB backend cserelheto, van hozza nagyon fasza migration megoldas is (South), ami cserehez annyira nem szukseges, ellenben a modellek valtozasait nagyon jol tudja kovetni, es segit a DB upgradeben, stb.

--
|8]

( Jason v | 2011. 01. 19., sze – 22:12 )

Ruby on Rails

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( Herakleitos | 2011. 01. 19., sze – 22:24 )

http://www.stripesframework.org/

2-3 éve használjuk Struts és Struts2 helyett. Kb. 10 alkalmazást írtunk vele (a legnagyobb esetén több mint 100 ezer regisztrált felhasználó - közigazgatási alkalmazás). Hatékony, megbízható, gyors, egyszerű.

"Csak a változás állandó." - Herakleitos ---> Használj VCS-t!

( Exit | 2011. 01. 19., sze – 23:32 )

Én a következőket javaslom:

Spring az aljára DI-nek
Spring Security a beléptetés/jogkezeléshez (és akkor azon keresztül lehet JAAS is)
Hibernate a db független db kezeléshez (JPA criteria apin keresztül + Springes tranzakciókezelés)
Apache Wicket az UI-hoz. Korábban Spring MVC-t használtam, de a wicket sokkal elegánsabb.

Mivel nem csak a frameworköket kérdezted, hanem a fejlesztőkörnyezetet is.
- Java 6: mert az összes többi régi. Ha az ügyfél nagyon igényli akkor le lehet adni 5-ösre.
- Maven 3 alapú projekt. Mert kényelmesen leegyszerűsíti az életedet, ami a függőségeket illeti.
- Servlet 2.5/3.0-ra és JPA-ra építkezés. Mert ez a két Java standard tényleg jó.
- fejlesztés Eclipse-ben m2eclipse pluginnal + Tomcat 7-tel. Mert én ezzel szoktam meg. De ez elvileg megy Netbeans-szel is meg IntelliJ-vel is.
- verziókövetés: svn vagy git. Eclipse-ben van plugin mindkettőhöz.

Ha a fenti frameworkökre építkezel az alkalmazásod hordozható lehet az alkalmazásszerverek és db-k között is.

( sfeher v | 2011. 01. 20., cs – 11:04 )

Icefaces-t használ valaki ? Egy ismerős benne találta meg az "igazit".

Nekem nem tűnt lassúnak, bár fizetős komponensekből egyet sem próbáltam.

A primefaces nem rossz, bár nem tudom, hogy mostanság mekkora fejlesztői gárda van mögötte. Ha jól tudom, akkor egy török srác kezdte és fejlesztgette az egészet az elején és becsületére legyen mondva, hogy nem rossz, amit művelt.
Bár nem kizárt, hogy most már odaállt mögé egy csapat és van "ipari" méretű support is akár, de én még abban az időben néztem, amikor még egyedül (max pár önkéntes bedolgozó) nyomta az ipart és még a fórumbejegyzésekre is szinte csak ő válaszolt. Szóval ilyen igazi kis one-man-show volt akkoriban. :)

( Nickname | 2011. 01. 20., cs – 12:02 )

http://zkoss.org tudom, ágyúval verébre, de előbb-utóbb mindenki galambra meg varjúra vált és a végén már csak pár lépés a csillagromboló. :)

( sfeher v | 2011. 01. 20., cs – 12:27 )

Hát ez az én bajom :). Annyi info-val nyomasztotok, hogy ember legyen a talpán, aki ebből kitalálja, hogy merre tovább :D:D.

Igazából azt kellene kitalálnod, hogy biztos, hogy kb. 0-ról akarsz-e fejleszteni, esetleg nem-e lenne jobb egy már meglévő portál rendszer, vagy hasonló, és csak a szükséges pár dolgot fejlesztenéd hozzá.

Ha egy általános keretrendszert használsz, ahol van egy adatbáziskezelő réteg (hibernate), egy keretrendszer, és egy prezentációs réteg (html/ajaxos gui), akkor minden úgy fog kinézni, ahogy szeretnéd, viszont egy csomó fejlesztési időt bele kell tolnod.

Ha egy portál rendszert, vagy valami hasonlót találsz, ami nagyjából lefedi azt, ami neked kell, és csak pár modult kell esetleg hozzáfejleszteni, akkor lehet, hogy sokkal jobban jársz.

Szerintem a projekt előtt nézz körül, hogy kb. mi az, ami elérhető a piacon, és érdemes ezt is a serpenyőbe pakolni...

Ja, ezt még felírnám esetleg a listára:

http://www.playframework.org/

"Ez mondjuk egy baromi jó kérdés, hogy lehet ezt megoldani?"

A portleteknek közösségenként, az insatncable portleteknek meg példányoként saját adathalmazuk van. Persze lehet jogosultságot adni hogy quest is megnézhesse, illetve 1 felhasználó tartozhat több közösségbe is, ezzel nem lesz probléma. A Liferayt egyébként én is csak ajánlani tudom:

- MVC modell megvalósítható vele (nem gányolás útján) [Liferay MVC, meg használhatsz sajátot is Spring, Struts]
- Hatékonyan használható, könnyen tanulható [Nyilván mint mindennél komolyabb dolgokhoz mélyebb ismeret kell, de a hookok meg extek segítségével a Liferayben csak az eltérő működést kell definiálni ha LRes cuccot akarsz átírni]
- Széles körben használt, szabványos [Asszem ezzel nincs gond]
- Az alkalmazás adatbázis függetlensége megvalósítható vele (ez nem biztos h fw kérdése) [Az alap LR valami 20 féle db-t támogat, a custom portleteknél neked kell erről gondoskodni]

A leendő alkalmazásról néhány gondolat:

- user,group,acl szintű jogosultságkezelés (JAAS?) [LR nem eléggé széleskörű user kezelése van, ugyanis vannak szerfezetek, közösségek, csoportok, teamek, szerepkörök, na meg a felhasználók. Ha ebből nem tudod kihozni amit szeretnél semmiből :D]
- Fontos lehet az alkalmazás elkülöníthetősége (profil ?) (pl. két különböző felhasználói csoport ua. az app-ot használja más db-vel) [erről írtam]
- Legyen jól skálázható [Bár nem tudom ilyen felhasználószámnál ez miért kritérium, de EE liszensz vásárlása esetén van mód a cluster üzemmódra, csak pénztárca kérdése]

Nice to have:

- Formok definiálási lehetősége pl. xml-ből (az oldalon X csoportnak X formot mutatom és validálom, Y-nak Y formot.) [Létezik web-form portlet bár magam sosem próbáltam]
- Riportolásra valami jó kis tool (JasperReports ?) [erről nem tudok nyilatkozni]
- Lehetőleg problémamentesen cserélhető legyen a DB backend, ha szükséges [erről is írtam, a támogatott dbken kívű van import/export cucc, ami közösségenként teljes közösséget minden beállításávál tartalmával együtt kezel]
- Külső rendszerkapcsolatok (pl.web service) lehetősége [Alapból Axis van benne, a legtöbb belső szervíz ki is van ajánlva soap szervízként is, a sajátoknál meg azt használsz ami tetszik]

Amúgy ágyúval verébre :D

java'nother blog

Ez a feladat részemről (illetve kollégáim részéről) egy tanulási folyamat kezdete. A projekt elég kicsi ahhoz, hogy kezelhető legyen egy a témában még járatlan team számára, de elég komplex ahhoz, hogy kidolgozzunk egy megfelelő irányt (eszközök, framework, app szerver stb.) a továbblépéshez. Ez kellene a lehető legkisebb kerülőúttal elérni.
Nem rettenünk meg a 0-ról való fejlesztéstől, de nyilván fel szeretnénk használni már kész eszközöket, megoldásokat, tapasztalatot, know-how-t.
Tudom, hogy elég sok a kérdőjel a dologban, de azért bizakodó vagyok a hozzászólások alapján.

Még valami eszembe jutott. Mielőtt nekiálltok bármit is kódolni, pontosan kérdezzétek végig a megrendelőt, hogy mit szeretne, csináljatok rajzokat, webterveket, és azokat mutogassátok nekik, és mondassátok vele szépen végig, hogy mit is akar használni, és hogyan.

Ebbe már párszor belefutottunk, és ilyenkor derül ki, hogy mi az, amit simán csak lekódol az ember, meg mi az, amire csinál egy kis felső framework-öt...

( Arbiter | 2011. 01. 20., cs – 14:38 )

Oracle ADF a framework és JDeveloper az IDE, bár lehet, hogy ide ágyúval verébre lesz.

( syntern | 2011. 01. 20., cs – 17:44 )

A követelményeid nagy része nem web framework függő, egy ilyen felhasználószámra szinte bármelyik felsorolt jó. A Wicket, Stripes, JSF hármasból célszerű kiválasztani azt, ami a fejlesztőknek a legszimpatikusabb, és azzal végigcsinálni. Én nem annyira hiszek az XML-es definiálásokban (bár már csináltam field-level security interceptort JSF-hez), ha hardcore Java kódereid vannak, akkor a Wicket jó választás lesz, mert sokkal jobb szinten tudod szabályozni a tulajdonságokat, mint a legtöbb ilyen form definícióban, amit eddig láttam.

A JAAS kulcsszót elkerülném, nagyon enterprise és ritkán életszerű dolgokra találták ki, kis projektnél bőven jó egy kis kézi hekkelés, bár a legtöbb webes framework támogat annotáció/konfig alapú biztonságot, eddig nem láttam olyan feladatot, ahol az okos kézi kódolás túl nagy lett volna ezekhez képest (cserébe sokkal rugalmasabb).

A DB backend cserélése nem technológiai, hanem fejlesztésfüggő, ha elkerülitek a vendor-specifikus dolgokat, akkor nyilván könnyen le tudjátok majd cserélni. JPA könnyen tanulható, bátrabbak használhatnak helyette Spring JdbcTemplate-et. Az ugyanaz az alkalmazás más DB-vel egy nagyon érdekes kérdés, egypár interceptor logikával lehet ilyeneket csinálni, de azért jó lenne tudni, hogy mennyire fontos, nem egyszerűbb az, ha van két külön bekonfigurált deploy a két külön adatbázishoz?

Ha be kellene mondani egy stacket, akkor én a Spring + JPA + Wicket + Jetty + Eclipse-et javasolnám egy kezdő projektnek, a követelmények nagy részét egyszerűen meg tudjátok vele oldani, nincs brutális overhead az eszközökben és jól karban tartható. Vaskalapos enterprise vonalon el lehet menni JBoss Seam + társai irányba, ha fizetni is akarsz, akkor Oracle, de nem biztos, hogy a kezdeti látványos drag-and-drop funkcionalitás visszajön akkor, amikor az apróságokat kell hozzárakni a felülethez.

Indulásnak ennyi, aztán számolj majd be arról, hogy mire jutottál :)

Az ugyanaz az alkalmazás más DB-vel egy nagyon érdekes kérdés, egypár interceptor logikával lehet ilyeneket csinálni, de azért jó lenne tudni, hogy mennyire fontos, nem egyszerűbb az, ha van két külön bekonfigurált deploy a két külön adatbázishoz?

Ez szerintem tökéletesen megfelel a célnak. Kezdetben biztos.

A JAAS nem egy rossz cucc. Én tartottam tőle, de aztán egyszer beadtam a derekamat és spring securityn keresztül használtam. Nagy előnye, hogy nem kell tudnod valójában hogy is fog menni az autentikálás és honnan jönnek a jogosultságok. Csak leadod a wart, ami egy loginban kér user-t meg pass-t és a JAAS másik felét be lehet konfigurálni az alkalmazásszerverben (de akár tomcatben is). Van ahol ez jól jön (ahol pl. már van egy user kezelés és ahhoz kell integrálódni és az ügyfélnek van is ehhez passzoló alkalmazásszervere), mert így könnyen integrálhatják amihez akarják (LDAP-hoz, AD-hez, DB-hez, txt-hez, egész pontosan ahhoz amit az app szerver támogat) anélkül, hogy az alkalmazáshoz hozzá kellene nyúlni.

A stack-ben egyébként egyetértünk, én is ezt javasoltam fentebb.

( sfeher v | 2011. 01. 20., cs – 20:59 )

Az még érdekelne, hogy pl. a mit nyerhetek alkalmazás szerverek terén egy container-el szemben (glassfish vs. tomcat vagy jetty ?)

Flancos admin felületet. :)

Viccet félretéve: szerintem, ha nem kell semmi olyan JEE feature, ami a servlet container-ben nincs meg (pl.: JMS), és a megrendelő sem ragaszkodik hozzá, akkor a Tomcatnél nincs jobb választás. Egyébként a Glassfish 3 egész jó cucc, dolgoztam vele, de ott is csak azért nem lett Tomcat, mert a management úgy döntött (így lett elég enterprise-os az érzés).

( talisker | 2011. 01. 21., p – 00:22 )

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( sfeher v | 2011. 02. 12., szo – 17:11 )

update3:

Most modellezem a különféle megoldásokat. Kerestem a Netbeans-ben a Visual Editor-t, de szépen kivették belőle :(. A 6.5.1-ben van meg utoljára. Tudom, a design legyen a designerek dolga, azok meg ne matassanak a nb-ben, de azért mégis.. A jelenlegi 6.9-ben nyoma sincs. Szóval elkeserítő picit a helyzet ebből a szempontból.
Ki, hogy oldja meg ezt a kérdést ? (Külön tool-t használ (pl. DW), kézzel rakja össze az oldalt stb.)
Köszi.

Hat, wysiwyg valoban nincs, viszont windowson van weboldal elonezet, meg css elonezet is. CSS-hez van mondjuk linuxra is cucc, flyingsauce alapokon, de az nekem neha kicsit hulye.

De amugy is, a JSF koraban mar ugyis minden XHTML, arra meg van nagyon sok jo cucc (Dw, Bluefish, nvu, etc.)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( palyesz | 2011. 05. 23., h – 23:18 )

subsrcibe

---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering

( sfeher v | 2011. 05. 30., h – 14:22 )

Az UML modellező plugin sem része már a Netbeans-nek (6.7-ig benne volt)
Jöhetnek az alternatívák UML modellezésre. (tudom, ne használjak nb-t).

( sfeher v | 2011. 05. 30., h – 14:27 )

Lassan felgyorsulnak az események :).
Tesztelésre ki mit javasol ?

Replacement-nek nem mondanám, a Selenium webes GUI teszteléshez remek, a JUnit-ot ennél azért mélyebb szintre pozícionálnám a tesztelésben.
Nem szükséges hozzá alapból teszt framework, de képes együttműködni más teszt frameworkökkel is, mint a JUnit vagy a TestNG. Ezért én inkább azt mondanám, hogy nem fölé, hanem mellé, aminek egyébként kiváló integrációs lehetőségei vannak.

( gejzir | 2011. 05. 30., h – 14:47 )

Wicket (http://wicket.apache.org/)
érdekes lehet még a wicket alapú BrixCMS (https://github.com/brix-cms)

Vaadin alkalmazás frameworknek nagyon jó
(http://vaadin.com/home)

Ami még ígéretesnek tűnik, de nem használtuk még az a SpringRoo (http://www.springsource.org/roo)

Azt látom, hogy sok mellékvágány útján kezdenek a java web frameworkök végre letisztulni, egyszerűen, gyorsan, tisztán és hatékonyan nagyon látványos eredményeket lehet elérni wickettel, vaadinnal, ZK-val.

Wicket:
-sokkal inkább web ÉS application framework
-a layout xhtml-ben megadható, külső eszközzel szerkeszthető -> designernek oda lehet adni.
-szinte bármilyen xhtml kimenetet tudsz vele varázsolni, persze a kész widgetek megkötik a kezed.
-nagyon egyszerű benne bármilyen további saját egyedi widget gyártása (panel).
-nem áll mögötte cég, eléggé szét vannak szórva az infók és a kész widgetek a weben

Vaadin
-sokkal inkább application framework
-sokkal több gyári komponens
-nincs xhtml, xml kód a layout megadáskor, csak tiszta java kód.

-cég van az egész mögött, vehetsz céges supportot és extra vidgeteket.

( sfeher v | 2011. 05. 31., k – 21:01 )

Végül, de szerintem nem utoljára a fejlesztői környezetről, infrastruktúráról szeretnék begyűjteni minél több információt.
A következők a tervek:
- A fejlesztők localhost-on fejlesztenek, tesztelnek elsődlegesen (SVN, közös Maven repo)
- Lenne egy teszt szerver, ahova időnként deploy-olnánk a kész cuccot.
(Itt lenne a részletes teszt, mielőtt élesbe kerül a rendszer.)
- Harmadik lépcsőként jöhetne az éles rendszer
Érdekelne pl. a projekten belüli csomagok (Business Logic, DAO stb. mit és hogyan érdemes csomagolni) vagy akár az SVN repo célszerű felépítése.
Köszi.

Engem most meg fognak itt kövezni, de a mavent csak akkor használd, ha ismered és pontosan tudod használni. Én a mavennel eddig csak szívtam, pedig értek hozzá, hatalmas projekteken használtuk, saját plugint is írtunk, de azóta is kerülöm mint lábammal a vizet.

Saját erősen szubjektív vélemény:
Kis projekten nem éri meg használni.
Közepes, nagy projekten vannak előnyei, de szerintem lassú mint a dög és hatékonytalan.
Nagyon nagy projekten viszont extra szívás. Mi konkrétan a maven miatt éjszakáztunk 3x egyébként triviális dolgok miatt és csúsztunk heteket.

Én maradnék ant-nál.

Verziókezelés:
Ez engem is érdekel, ha valakinek van tapasztalata, ossza meg. Mi mostanság akrunk váltani svn-ről (ami ugye centralizált) valami distributedre, pl. git vagy mercurial.

Distributed version control esetén viszont okosan célszerű kialakítani a repository struktúrát (több hierarchikus szinten), hogy az előnyeit ki tudd használni.

Szoftver belső architektúra:
Bármilyen szoftvert írsz (akár desktop alkalmazást is) célszerű szétválasztani bizonyos funkcionális rétegeket. A business logic, a view mindenképpen különüljön el, akkor is, ha nem használsz EJB-ket vagy enterprise technológiát.

Maven builds are an infinite cycle of despair that will slowly drag you into the deepest, darkest pits of hell (where Maven itself was forged).
:D

Biztos nem röhögnék 3 nap éjszakázás után, bár nekem is volt részem ilyenben bőven, de ott nem a maven volt a bűnös :).
Ami számomra eddigi negatívum, hogy a build ideje nagyságrenddel megnőtt.
A projekt egyébként nem lesz nagy, kb. tizes nagyságrendű külső lib kell hozzá terveim szerint, ezt kezelhető mennyiségnek tartom.

Nekem kezdo Java-skent foleg azert tetszik a Maven, mert letolt minden fuggoseget, ami nekem kell, nem kell a verziokezelot terhelnem a binaris blobhalmokkal. Aztan, ha nagyon nem tetszik a viselkedese, a build folyamatban mar hasznalhatok ant kifejezeseket.

Viszont ez a -o kapocsolo ez nagyon hasznos dolog.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Maven repo nagyon nagy josag. Sajat repo meg nagyobb.(artifactory)

Amikor az ember kisse szokatlan dolgot akar,meg ha nagyon egyszeru dologrol is van szo, tenyleg van nagy tanakodas hogyan is kene ravenni a maven-t.

Viszont van jo par varazs pluginja, ami nagyon komplex dologot megtesz nagyon egyszeruen.

A nagy bajom vele, hogy nehezen tudom osszeegyeztetni pl. a gentoo build rendszerevel, pont azert mert maga kezeli fuggosegeket es letolteseket is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

En ugy szoktam, hogy ahol bizton szukseg van maven-re, rubygems-re, cpan-ra, vagy barmi olyanra, ami a gentoo build rendszerevel osszeegyeztethetetlen, ott csak az alaprendszewrt huzom fel emerge-vel, onnantol a build rendszerre hagyatkozom. Igy nincsenek osszeferhetetlensegeskedesek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én azért fordultam ehhez, mert nem akartam már ant-ot és el akartam kerülni a mavent. Mivel gyorsan fejlődő stádiumában kapcsolódtam a használatába, voltak még gyermekbetegségei (nem tudom most hogyan áll a helyzet, mert amit kialakítottam, ahhoz már jó ideje nem kellett hozzányúlni :-). Általában a verzióváltások során voltak kisebb döccenők. Aktív a lista, segítőkészek a fejlesztők.

( sfeher v | 2011. 06. 03., p – 21:43 )

Miért netbeans vagy miért eclipse ? pro/con pls.
Tudom szubjektív meg hitvita, de komolyan érdekel.

Én csak azt tudom megmondani, hogy mért/mikor ne Eclipse:
Ha hálózati meghajtón dolgozol pillanatok alatt crash lesz a vége. Pár kb a vágólapra és szétesik az egész rendszer...
Nem tudom, hogy az újabb verziókban megoldották-e ezt, de a NetBeans és én tökéletesen megvagyunk, úgyhogy nem is igazán érdekel.

Mindhárommal (NB, Eclipse, Idea) dolgoztam eleget ahhoz, h legyen tapasztalatom.
Az általuk kínált szolgáltatásban talán nincsenek nagy eltérések, bár mindig lehet olyanokat találni, ami valakinek hiányzik az egyikben, de megvan a másikban. Sokáig a fő ellenérv az összehasonlításban az ár/érték arány volt, amiből -lévén akkor fizetős - az Idea volt hátul. Azóta a community verzió ingyenes lett. Az "enterprise" funkcionalitásért fizetni kell. Nota bene, ha valaki egy összeszedettebb verziót akar Eclipsből, azért is fizetni kell, ha kevesebbet is.
(Kérdés persze, h kell-e ezen spórolni akkor, amikor a produktivitásban bőven visszajön az ár...)
Használhatóságban, átgondoltságban, dizájnban, a gond nélküli verzióváltásokban, pluginekben nálam toronymagasan vezet az Idea.

Felraktam, kiprobaltam. Nem rossz, de nekem a NB utan nagyon nehezkes a hasznalata, nem all kezre.
Azt kulon fajlalom, hogy a Ruby, Python, etc. az kulon editor, nem lehet - vagy nem talaltam meg, hogyan lehet - pluginkent felrakni oket.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Gyanítom, h némi használat után rá fogsz jönni mennyivel logikusabban felépített és kézreálló minden az IDEA-ban.

A plugin dolgot nem értem:
Settings/Plugins/Available és látok Ruby és Python plugineket

A gugli "intellij idea ruby" ezt adja:
http://www.jetbrains.com/idea/features/ruby_rails.html

En pedig felraktam, es azt mondja, a Ruby plugint nem tudja betolteni. Erre az oldalra visz, segitsegnyujtas helyett: http://confluence.jetbrains.net/display/RUBYDEV/RubyMine+and+IntelliJ+I… . Attol, hogy a listaban szerepel, meg nem mukodik.

Szerk: kis google, es megoldas: http://stackoverflow.com/questions/2597473/intellij-and-ruby-plugin-won…

Szoval nekem felejtos, ahhoz, hogy kiprobaljam, nem fogok fizetni erte. Ha jo, akkor, esetleg, talan. De addig nekem a NetBeans tokeletes.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( sfeher v | 2011. 06. 11., szo – 22:09 )

Kezd elkapni a harctéri idegbaj..
Valaki nézze már meg légyszi, hogy az alábbi példa működik e nála ?
http://www.mkyong.com/wicket/wicket-spring-integration-example/
Mert nálam rohadtul nem megy. Semmivel :(.

Ezekkel próbáltam:
nb 6.7.1, nb 7.0
maven 3.0.3
win és linux alatt, glassfish 3.1, tomcat 7.0, tomcat 6.0
jdk 1.6.0_25-b06

Ua. az eredmény:
Unexpected RuntimeException

WicketMessage: Markup of type 'html' for component 'com.mkyong.user.FileUploadPage' not found. Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried.: [Page class = com.mkyong.user.FileUploadPage, id = 0, version = 0]

Köszi!

Eclipse + m2eclipse plugin-nal így működik:
- zip kitömörít
- .settings mappa, .classpath, .project fájlok törlése
- Eclipse-be beimportál mint maven project
- build + deploy + start Tomcat 7-be
- behív nyitó oldalt, örül.

Egyébként az alapvető baj az a példával, hogy maven alatt default-ból a nem java fájlokat nem a src/main/java alá kellene tenni, hanem a src/main/resources alatt lenne a helye. Úgyhogy ha könyvtárhelyesen áthúzod a .html-t a java könyvtárból a resources-ba, akkor feltételezem a NetBeans maven pluginja is képes lesz helyesen kezelni.


Egyébként az alapvető baj az a példával, hogy maven alatt default-ból a nem java fájlokat nem a src/main/java alá kellene tenni, hanem a src/main/resources alatt lenne a helye.

Nb alatt a wicket plugin az src/main/java alá rakja a html-t is.
Átraktam a resources-ba, semmi változás. Pénteken olvastam egy olyat, h valakinek nem minden fájl került be a war-ba valami bug miatt.
Megnéztem az enyémet is, egy darab html sem volt benne, a maven szépen kiszűrte nekem. Az alábbi rész a pom.xml-be iktatásával rávettem, hogy ne tegye ;). Most megy szépen.
Köszönöm a segítséget..

(Amúgy atom, hogy valaki legyárt egy demo-t, odarakja a forrást .zip-ben, ami elvileg kell, hogy forduljon bármiféle IDE nélkül és mégse megy. A kezdő user meg örül :).

pom.xml build részhez:
http://pastebin.com/WYmRpFGS

Szvsz itt alapveto nyugok vannak.

Eloszor is, a html fajlok a webapp reszei, nem resourcok, es foleg nem java kod.

Tessek a war plugin mukodeset elolvasni itten: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filter…
Utana pedig at kene strukturalni a projektet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Wicket eseten a komponensek templatjei, amik egyszeru html fajlok, a classpathrol vannak olvasva, ugyhogy semmi shame nincs benne. Ez a def mukodes:
foo.bar.MyPanel.java es hozza foo.bar.MyPanel.html
Azert van igy, mert igy az ui komponensek jar-ba csomagolhatoak es fuggosegkent bedobalhatoak barmelyik web projektbe. Annyi, hogy en a resource-s alatt tartom oket, mert onnan a pom.xml buvolese nelkul is bekerulnek a leforditott classpathra a java melle.

Ha sima jar-okat forditasz, akkor igen, lehet. Ha azonban war fajlt csinalsz, az a Maven-nel mas kategoria, mas plugin dolgozza fel a pom.xml-t. Attol, mert mukodik a resources mappabol is, meg nem feltetlen oda valo.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az lehet, de a maven war pluginjenek van egy szemlelete, amit erdemes lehet kovetni, mert a jovoben lehet, hogy nem ugyanugy fog mukdoni a ket dolog. Az hogy most olyan, az nem jelent garanciat a jovore nezvest.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha ezt megtennek egy bugot raknanak a rendszerbe. A classpath szintu resource-ok felett a war pluginnak nincs joga rendelkezni. Egyetlen dolgot tehet vele: elerhetove teszi, ahogy a class-okat is.
Erre mar az is eleg indok, hogy a resources mappa configja nem plugin belugy, hanem projekt szintu. Valoszinu, hogy a compiler plugin kezeli minden esetben (akar jar akar war a csomagolas tipusa).
Az is valotlanna tenne egy ilyen modositast, filterezest, hogy a Servlet 3 egyik uj funkcioja, hogy a /META-INF/resources alol, a classpathrol, is kiszolgal resourceokat (pl.: http://localhost:8080/mypic.png eseten a png lehet egy jarban az emlitett konyvtarban).

A "webapp" mappa ezzel szemben war plugin specifikus. Konfigolni is a war plugin szintjen kell (ha valaki akarja). Ezzel vegezhetnenek backward incompatible valtozasokat, de ezt sem tartanam valoszinunek, a mavenesek kifejezetten sok energiat forditanak arra, hogy a verziovaltasok visszafele kompatiblisek legyenek (lasd 2 -> 3 valtas).

( sfeher v | 2011. 06. 16., cs – 20:23 )

DI (Dependency Injection) miért jó nekem ? Ha valaki röviden leírná...
(A működést értem, de lényeget még nem látom..).

Gondolom a wiki cikkeket már olvastad ([1], [2]). Ha buzzwordoket kellene mondani, akkor decoupling és loose coupling valósítható meg vele.

Pl.: van egy dao interface-d, adatelérési műveletekkel. Van egy pure jdbc db alapú implementációd hozzá. Akkor regisztrálod a dbdao-d példányát a DI-ben és azok az objektumok, amiknek erre van szükségük, automatikusan megkapják ezt, amikor létrejönnek. Ha cserélni akarod (mondjuk hibernate alapúra) egy másik implementációra, akkor elég ezt az egy regisztrációt lecserélni, minden ettől függő egyéb objektum innentől az újat fogja megkapni.

Régebben setter alapú injection volt az általános, de a good practice nevében ma már a konstruktor alapú injection a menő, úgyhogy ezt érdemes szem előtt tartani.

Ahogy én látom két népszerűbb van a spring meg a guice. Szvsz. tisztán a DI funkcionalitás miatt nem lehet ma már dönteni, sokat számít, hogy mi mást használsz még ezekből a frameworkokből. Én a spring-et használom, mert már akkor is használtam, amikor még nem volt guice és nincs vele semmi gondom. Az xml alapú konfigjával sincs bajom ugyanis ezzel kapok egy kész konfigurációs megoldást is (db elérések konfigurálása az ügyfélnél simán egy módosítás a spring xml-ben). Ezen kívül is sok spring alapú cuccot szoktam használni (spring security, hibernate/jpa támogatás, apache cxf, régebben spring mvc, ...).

1 DI: http://en.wikipedia.org/wiki/Dependency_injection
2 IoC: http://en.wikipedia.org/wiki/Inversion_of_control

( sfeher v | 2011. 06. 17., p – 16:13 )

Két db között kellene majd adatokat szinkronizálnom, az egyik oracle a másik meg valami a mysql,postgres,oracle hármasból.
Az egyik felén van egy kliens/szerveres app, a másikon meg amiről a topic szólna. Adatcseréről illetve néhány bináris állomány (pdf) szinkronizálásáról lenne szó. Szerintetek hogy érdemes ezt megoldani ?
A db-k feltételezzük, hogy egymástól távol vannak. Valami web service-s megoldásra gondoltam első körben, de nyitott vagyok mindenre :).

Ennyi infóra nehéz jó ötletet adni, mert felmerülnek kérdések:
- mekkora adatmennyiséggel kell számolni (db esetén táblák, sorok száma, bináris esetén fájlok mennyisége és mérete)
- milyen gyakran kell szinkronizálni
- mit értünk szinkronizálás alatt: mindkét rendszerben egymástól függetlenül változhatnak az adatok és ezért két irányba kell szinkronizálni vagy az egyik csak backup
- az egymástól távol mit jelent: az interneten keresztül megy a kapcsolat?
(Kevésbé érdekes: a CRUD-ból minden játszik (insert, update, delete)? Táblák autoincrementesek? DB szerkezetet is kell szinkronizálni?)

Néhány általános javaslat a megoldáshoz (ettől létezhetnek optimálisabb megoldások is a fenti kérdésekre adott válaszok függvényében):
- szerver oldalra springes webalkalmazás amiben van egy apache cxf-es soap szolgáltatás
- kliens oldalon parancssoros spring app amiben ugyancsak cxf-fel könnyen elintézhető a soap rész
- ha a kapcsolat az internet akkor mindenképpen, de amúgy sem árthat, https + autentikáció kell (WS-security)
- bináris fájlokról fájlméret, hash, utolsó módosítás dátuma adatbázis fenntartása, szinkronizálás ezen infók alapján (hogy változott -e egy fájl)
- mivel több db is lehetséges jpa-t (egész pontosan hibernatet) javaslok a db kezeléshez

Nyilván általános megoldás nehéz adni. Néhány dolgot pontosítanék.

- adatmennyiség naponta néhány Mb, havonta egyszer néhány tíz Mb.
- a fájlokat havonta kell A-ról B-re eljuttatni
- az egyéb adatokat naponta néhányszor A és B között két irányban.
- nem, nem backupról van szó, hanem B reprezentál egy bizonyos adatkört A-ból, amit néha, megfelelő szabályok alapján kell szinkronizálni illetve eljuttatni egyik helyről a másikra (ott egy ember vagy egy algortimus már eldönti mi legyen vele).
- CRUD játszik, törölni nem nagyon kell
- a táblák egy része még nincs meg más részük nem autoinkrementes
DB szerkezetet nem szinkronizálunk csak rekordokat

Apache CFX, SOAP volt az első gondolatom. Szerver oldalon a Springes webapp adott lesz :).
A kapcsolatnál intranetes és internetes kapcsolatot egyaránt feltételezni kell, így SSL mindenképp illetve a web service auth is játszik.
A fájlok esetén elég lesz egy hash illetve egy timestamp, hogy mikoriak. Mivel itt kizárólag A-ból B-be vándorolnak a cuccok. Ezeket BLOB-ba kell majd raknom, a fájlrendszer itt szerintem nem lenne nyerő.
Megnyugtató, hogy nem lövök annyira mellé az elképzeléseket illetően.. :)

Így nem néz ki vészesnek a dolog. Pár szvsz megjegyzés:
- van már ötleted arra, hogy hogyan fogod kiszűrni az új/módosult/törölt sorokat? Ha van timestamp a sorokon akkor lenne talán a legegyszerűbb.
- "az egyéb adatokat naponta néhányszor A és B között két irányban", ezt azért majd pontosítani kell nehogy instant replikációt értsenek alatta :)
- sok új technológiát szándékozol használni, általában projektenként jó ha 1-2 újat szokott az ember bevezetni, úgyhogy ezek megismerésére szánj plusz időt


Így nem néz ki vészesnek a dolog. Pár szvsz megjegyzés:
- van már ötleted arra, hogy hogyan fogod kiszűrni az új/módosult/törölt sorokat? Ha van timestamp a sorokon akkor lenne talán a legegyszerűbb.
Még nincs lebontva a projekt ennyire részletesen. Ezzel szerintem nem lesz gond. Az adatmódosítások egyoldalúak lesznek. Ha B-n valami módosul, akkor az triggerel egy kérelmet, megtörténik a szinkronizálása B-ről A-ra, majd A dönt, hogy jóváhagyja e. Ha igen, akkor ack-ot küld B-nek, hogy rendben. A-ról B-re küldött adatok esetén pedig B meglátja mit küldött A, de nem piszkálhat bele, mivel ezek read only dolgok (adatközlés, információ.)

- "az egyéb adatokat naponta néhányszor A és B között két irányban", ezt azért majd pontosítani kell nehogy instant replikációt értsenek alatta :)

Semmiképp. Én határozom meg a gyakoriságot illetve a módszert is. Az ügyfél meg használja.

- sok új technológiát szándékozol használni, általában projektenként jó ha 1-2 újat szokott az ember bevezetni, úgyhogy ezek megismerésére szánj plusz időt

Hát igen. Ez az egyik fájó pont. Arra gondoltam, h inkább két héttel több szívás, de legyen rendesen kitalálva és végrehajtva a projekt.
Nem cél a bleeding edge technológiák hajhászása, de mivel idegen területre léptünk ezért minden új.
Amúgy erősségem a helyzet gyors átlátása :). Ami viszont megnyugtató, hogy közel húsz év fejlesztői múlttal még mindig vannak olyan eszközök, megoldások vagy feladatok, amik hihetetlenül inspirálnak. Szóval kis lépés az embernek, hosszúlépés meg nekem ;) és mindenkinek aki hozzáértő és segítő szándékkal ellát információkkal.

Mint abszolút hozzá nem értő :), fogalmam sincs.

Ha csak gépek lesznek a játékban emberek nélkül, akkor elég a JAX-WS. Ha emberek is akarják használni (szép webes felület etc.), akkor használj spring-et is.

Nem olvastam az egész topic-ot, de úgy érzem eléggé képbe kerültem ahhoz, hogy beledumáljak.

A framework legyen spring-es. Én mindenképp a hármas spring-et javasolnám.
A spring web mvc-t gyönyörűen lehet annotációkon keresztül konfigurálni (@RequestMapping).
A gép-gép kommunikációhoz pedig JAX-WS-t ajánlok. Szintén gyerekjáték annotációval létrehozni a szolgáltatásokat (@WebService).

A maven is remek döntés, tanuld meg használni a különböző package type-okat (legalább az alapokat: JAR, WAR, EAR). Nagyon hasznos lehet a jövőben bármelyik projekt-nél.

Alkalmazás szervernek mindegy mit használsz. A fenti kombinációt egy mezei web container is kezeli (akár egy jetty is elég). Természetesen ha kinövi a rendszered a terét, akkor érdemes egy könnyen clusterezhető megoldást választani (a legtöbb AS erre is ad támogatást).

Lehet, hogy elég, végül is a Java6-ban benne van. Nincs vele tapasztalatom, mert amikor legutoljára néztem nem találtam olyan példát, hogy a JAX-WS szolgáltatásomat sima war-ként összecsomagolva bedobhatom egy tetszőleges (nem módosított) servlet container-be (2.5+), ami egy tetszőleges (nem feltétlen sun-os) jdk-n fut (5+) és működni fog. CXF-fel meg ezt megkapom.

Ez tényleg attól függ mennyire tudod kontrollálni a cél környezetet. A munkám során nekem sok megrendelő sok környezetével volt már dolgom és sokszor már meglévő infrastruktúrához kell igazodni (OS, DB, servlet container - AS, JDK mindenféle kombinációban és így volt köztük ibm és jrockit jdk is). Nekem ezért fontos, hogy mindent a war-ból tudjak intézni valóban platform független módon.