JAVA swing vagy JAVAFX?

Java

Sziasztok!

Jelenleg, ha akarok egy GUI feluletet letrehozni (vastag kliens), akkor azt most melyikbe kellene megvalositanom, java swing vagy javafx-ben?
java swing mar elevultnek tekintheto?

  • 9776 megtekintés

( sz332 v | 2013. 02. 08., p – 11:59 )

Szia,

JavaFX 2 most jön fel - az 1-eshez még bottal sem szabad nyúlni - viszont szerintem még elég sok bug/hiányosság lehet benne, szóval ha biztosra akarsz menni, akkor a swing-et válaszd. Ez utóbbinak a nyűgjei tudottak, van hozzá jó sok könyv, anyag, tutorial, és biztosan nem akarsz abba belefutni, hogy a projekt közepén futsz bele egy olyan hibába, amit csak lib szinten lehet orvosolni.

Persze ha játszós projekt, akkor inkább JavaFX 2.

Arra azért figyelj, hogy már javafx 2-van, ami koncepcionálisan más,
mint amilyen a javafx1-volt, visszatértek a normális java-ban történő
programozáshoz, és felejtik a saját script nyelv használatát.

Nekünk olyan problémáink voltak, hogy RTL nyelveket amikor néztük még nem támogatott, hogy a komponensek méreteit kódban kell megadni, hogy linux alatt talán nem is volt elérhető, illetve
hogy külön kellett leszedni. Ezekből már pár dolgot megoldottak, szóval a jövőre nézve valószínűleg átállunk majd javafx-re, de most még nem...

( Exit | 2013. 02. 08., p – 12:35 )

Ha van ra lehetoseg, akkor erdekelne, hogy miert vastag kliens es miert nem webes?

ezt kifejthetned bovebben: Ha van ra lehetoseg, akkor erdekelne, hogy miert vastag kliens es miert nem webes?

Elso korben azert akarok vastag klienses gui-t, mert egy nyilvantarto rendszert szeretnek megvalositani benne sok sok muveletet belepakolva. Ez szerintem konnyebb vastagkliens formaban megcsinalni,

"Elso korben azert akarok vastag klienses gui-t, mert egy nyilvantarto rendszert szeretnek megvalositani benne sok sok muveletet belepakolva. Ez szerintem konnyebb vastagkliens formaban megcsinalni,"

Ez az erveles szamomra nagyon homalyos, de Te tudsz tobbet a megrendelo igenyeirol... Mindenesetre mielott belevagsz, foltetlenul probalj ki par komponens-alapu fw-t (GWT, Vaadin, zKoss, stb.). Ne csak azt figyeld, hogy szamodra mivel konnyebb a fejlesztes, hanem azt is, hogy majd miyen formaban lesz kenyelmesebb hasznalni. Cegek nagyon szeretik a webes feluletu alkalmazasokat - nem kell minden kliensre kulon telepiteni, egyszeru az update, elerheto mindenhonnan...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( zoli78 | 2013. 02. 08., p – 23:44 )

A swing és a javafx közül meg egyiket se ajánlom igazán. Akkor már inkább az Eclipse vagy Netbeans platform.

A webes keretrendszerekkel meg ez a tapasztalatom:

Wicket-eztem éveken keresztül. Még viszonylag a jobbak közül való, de van bőven szívás azzal is (az egyik pont abból fakadt, hogy minden a Wicket saját WebPage, WebComponent stb osztályaiból öröklődik és ráadásul a konstruktorban csinál olyan dolgokat, amivel gondod lehet, mert esetleg még nincs maga a teljes osztály inicializálva.)

A GWT-t azonnal felejtsd el, ha nem arról van szó, hogy van sokezer felhasználód és amit csak lehet ki akarsz tolni kliensbe js-be és ezért cserébe hajlandó vagy bevállalni egy nagy adag szívást a java -> js compilerrel és azzal, hogy nem fogsz tudni JUnit teszteket írni.

Nekem ami viszonylag bejött az a JSF 2, de sajnos másik projektre kerültem...

Swing és javafx-es hozzászólást nem értem, kifejtenéd? Ha arra gondolsz, hogy egy csomó minden swing-re
épülő plusz funkciót (dokkolható ablakok, etc.) nyújt a Netbeans vagy Eclipse RCP platform, azzal egyetértek, kérdés, hogy neki szüksége van-e erre.

GWT: mi használunk gwt-t, igaz, smartgwt-t. Teljesen jól működik, alátoltunk egy REST+JSON interface-t,
és azon keresztül kommunikál a weboldal a szerverrel. Mi JUnit teszteket a szerver oldali üzleti logikára írunk, és nem a kliensre (miért is kellene?) Java->js compilerrel sosem volt semmi gondunk, tökéletesen működött, sőt, simán tudtunk hívni javascript funckiót. Az igaz, hogy megvan a saját kis nyavajája a GWT-nek, különösen amikor egy komponens nem úgy működik, ahogy az ember ezt elvárja, ennyiből talán ez hátrány, viszont nem kellett megtanulni a javascript-et és még valami könyvtárat, hanem elég gyorsan neki tudtunk haladni már a projekt elejétől.

"és azzal, hogy nem fogsz tudni JUnit teszteket írni."

A functional/acceptance/GUI/ent-to-end tesztekhez hasznalhatsz Seleniumot JUnit-bol, GWT nem fog bekavarni.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Itt kapcsolodnek be, de egy picit off kerdessel: van valami egyszeru, konnyen ertheto howto arra, hogy hogyan kell Selenium teszteket csinalni, majd ezeket JUnit-bol hivogatni? Lehetoleg Selenium IDE nelkul - nincs olyanom, es nem is szeretnek. Keresgeltem a neten, de egy ido utan elvesztettem a fonalat.

Ruby/Rails alatt ilyesmi tesztelesre Cucumbert hasznalok, ez kepes elvben selenium backenddel is dolgozni, leirom, hogy mit szeretnek tesztelni, a mogottes kodban pedig az oldalon kb. DOM-szeruen haladok, es idonkent hivok egy click() fuggvenyt, vagy valami hasonlo fuggvennyel kitoltom az illeto beviteli mezot. Valami hasonlo faek egyszeru dolgot keresek Javahoz.
-- 

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

"A GWT-t azonnal felejtsd el, ha nem arról van szó, hogy van sokezer felhasználód és amit csak lehet ki akarsz tolni kliensbe js-be és ezért cserébe hajlandó vagy bevállalni egy nagy adag szívást a java -> js compilerrel és azzal, hogy nem fogsz tudni JUnit teszteket írni."

Nem is tudom, melyik részébe kössek bele. Egy biztos: JUnit teszteket lehet írni GWT-s környezetben is.

( deje | 2013. 02. 09., szo – 13:29 )

Én speciel nem rajongok a swing-ért, windózon még úgy néz ki, mint a natív win-es alkalmazások (a megfelelő LaF-al), de linuxok kimondottan rondák.
Programozni jó a swing-et, elég nagy szabadságot kap az ember. Az SWT szarabb ebből a szempontból, cserébe egyszerűbb, és natív widget-eket használ, szóval a nyomorult font renderelés is normálisan megy linux alatt. Cserébe vinni kell a plusz jar-okat.

Anno kipróbáltam még az Eclipse RCP-t, ez gyakorlatilag az a keretrendszer, ami az Eclipse-et is hajtja. Előnye hogy rengeteg funkcionalitás meg van valósítva, hátránya, hogy emiatt nem egyszerű megtanulni. Nekem 1 hetembe telt, hogy egy IMAP-os email klienst csináljak benne, viszont olyan GUI-ja volt, mint az Eclipse-nek, sőt, Eclipse alá pluginként is fel lehet tenni :)

JavaFX-het nem értek, de ha jól sejtem sokban hasonlít az M$ WPF nevű cuccához, amit viszont ismerek, és nem szeretem. Van sok előnye, meg teljesen át lehet szabni a kinézetet és egyedivé varázsolni vele mindent, de én személy szerint jobban szeretem, ha egy alkalmazás használja az OS által adott GUI toolkit eszközeit, és nem találja fel újra a spanyolviaszt. (ha nem tetszik a toolkit kinézete, majd én lecserélem OS szinten, de ne az alkalmazás feladata legyen ez)

Persze kabáthoz a gombot és nem fordítva, az adott feladat dönti el, hogy melyiket érdemes választani.

Linuxon egyedul a Nimbus LaF nez ki turhetoen, csak mindenki lusta azt megtenni, hogy ezen platform eseteben igy jelenjenek meg a cuccok.

Linuxra amugy nehez barmit csinalni, mert a "nativ kinezet" kifejezesnek itt nincs kezzel foghato jelentese. Nem egeszen trivialis eldonteni, hogy az adott kornyezetben mit ertelmezzunk "nativ" alatt.
-- 

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