[Javalist] Form & DB

[János Háber]

"Sajnos ebbol a harom dologbol egyszerre mindig csak kettot lehet
valasztani."

Agreed ;) Igazabol szerintem elegge teljes kepet adtunk arrol, hogy mik a
lehetosegek, a kompetenciakat ugy se ismerjuk, es donteni se mi fogunk :)

Boci


2013/2/2 Gábor Garami <gabor.garami at hron.me>

> A P/Invoke ott tud problemat okozni, ha nem csak hivogatni kell
> dolgokat benne, hanem oda-vissza adtcsere is kell, raadasul
> intenziven. Meg a Windows API-k tobbsegevel nincs kulonosebben baj,
> addig a 3rdparty DLL-ek eleg valtozatos minosegu belso implementacios
> koddal rendelkeznek, ami nem feltetlen felel meg a menedzselt
> kornyezet kovetelmenyenek. Nagyon sok cikket olvastam arrol, hogy a
> P/Invoke egy bizonyos szint felett frusztralo is tud lenni.
> Szemelyesen halistennek meg nekem se volt vele nagy problemam, pedig
> en nem is C#-ban, hanem VB.NET-ben fejlesztek .Net ala, ami neha eleg
> trukkos megoldasokat kovetel.
>
> Amit irtal (tanacskeres) az stimm, csak ettol meg nem lesz egyszeru
> egy ilyen tervre barmi epkezlab otletet adni. Kabe minden projekt
> menedzserek altali felvetesekor elhangzik (kimondva-kimondatlan), hogy
> legyen olcso es gyors a fejlesztes, es minel kisebb a vegtermek.
> Sajnos ebbol a harom dologbol egyszerre mindig csak kettot lehet
> valasztani.
>
> Garami Gábor
> E-mail: gabor.garami at hron.me
> Tel: +36 20 235 9621
> MSN: hrgy at vipmail.hu
> Skype: hron84
>
>
> 2013/2/2 János Háber <janos.haber at javaportal.hu>:
> > - Nekem az jott le hogy Miklostol tanacsot kertek: "- Nem én vagyok a
> > "kritikus", nem elsősorban nekem kell boldogulni vele,"
> > - Mivel egyikunk se tudja hogy a "kismeretu nativ exe" mennyire fontos
> > kovetelmeny igy lehet hogy megoldhato egy kisebb wrapper appal
> > (qt/.net/akarmi) de lehet hogy fontos kriterium az egesz alkalmazas
> meretet
> > tekintve.
> > - Nemtudom nekem Nativ DLL hivassal nem voltak rossz tapasztalataim :),
> > szempontkent peddig az alkalmazas kesobbi tovabbfejlodese szempontjabol
> > irtam.
> > - Mivel nemtudjuk hogy az adott fejlesztocsapat milyen nyelveket ismer
> (es
> > FreePascal is felmerult ugye elso korben) igy ez is fuggo kerdes, de az
> en
> > velemenyem szerint mindegyik nyelvnek megvan a maga helye plusz ekkora
> > projecthez nem erzem tul nagy ugrasnak a Java -> C# atallast (legalabbis
> > nekem nem volt az)
> >
> > Boci
> >
> >
> >
> >
> > 2013/2/2 Gábor Garami <gabor.garami at hron.me>
> >>
> >> Felreertetted a mondatot: el tudok kepzelni ilyen alkalmazast, csak a
> >> feladat felvetesebol az jott le, hogy nem akarnak tul sok eroforrast
> (ido,
> >> penz) belefeccolni a fejlesztesbe, illetve a kesobbi karbantartasba.
> >>
> >> Egyebkent FYI: .Net 3.5 ma mar minden tamogatott Windows verzioban
> megvan,
> >> vagy frissiteskent felmasz. Windows XP-re mar nem fejlesztunk nagyon.
> >>
> >> A webes megvalositas nekem azert jott be a kepbe, mert a leiras pont
> >> raillik egy ilyenre.
> >> A kismeretu nativ exe meg kimerulhet egy alapszinten osszerakott Qt-s
> >> bongeszoben, ami semmit nem csinal, csak behozza a webappot. Ilyesmit
> kb.
> >> egy-masfel nap keszre faragni, meg nagyon kodolni se kell hozza.
> >>
> >> Egyebkent meg nem kell bedolni a marketingnek. A P/Invoke (nativ dll
> >> hivasa .Net alatt) talan nagyobb szopas, mint a JNI. Nem beszelve arrol,
> >> hogy a kerdesben nem volt ilyen jellegu szempont, igy fogalmam sincs, ez
> >> miert erv.
> >>
> >> Nekem az a koncepciom, hogy ha lehet, nem tanultatok uj nyelvet a
> >> csapattarsakkal, ha a meglevo tudasbol is megoldhato a feladat. Talan
> >> rosszul gondolom.
> >>
> >> Garami Gábor
> >> gabor.garami at hron.me
> >> Skype: hron84
> >>
> >>
> >> Tel: +36 20 235 9621
> >>
> >> Sent from my T-Mobile G2
> >> Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.
> >>
> >> 2013.02.02. 23:20, "János Háber" <janos.haber at javaportal.hu> ezt írta:
> >>
> >>> - .NET 2.0-t azert mondtam mert a legtobb windowson van (a folott meg
> ki
> >>> tudja)
> >>> - " Ezek nelkul ma mar szerintem elkepzelhetetlen egy adatokkal dolgozo
> >>> .Net alkalmazas", hasznald az erot Luke :)
> >>> - A webes megvalositast azert is nem mondtam mert "kis méretű natív exe
> >>> előnyben", persze ettol fuggetlenul lehet appot kore wrappelni mondjuk
> >>> jettyvel, erre meg rajon barmilyen framework (mondjuk olyat nemnagyon
> >>> ismerek ami ORM nelkul tudna hasonlo fukcionalitast (saccoljuk be a
> veget
> >>> minimum 20M korulre)
> >>> - Persze ha van mas nyelv tudas (D, C/C++) akkor lehet azt is hasznalni
> >>> (wxWidgets, QT, GTK, FOX, es meg van egy tucat GUI lib ami hasonlot
> tud)
> >>>
> >>> De a leiras alapjan en meg mindig .NET -et ajanlanam
> >>>
> >>> -"Raadasul a .Net pont ugyanolyan nativ, mint a Java: semennyire."
> >>>   - nem allitottam hogy nativ, aztmondtam "Nativ windows kinezetevan"
> >>> (ezen felul JNI irasa nelkul kepes DLL-t kezelni ami akar elony is
> lehet a
> >>> kesobbiekben)
> >>>
> >>>
> >>> 2013/2/2 Gábor Garami <gabor.garami at hron.me>
> >>>>
> >>>> Bocsanat, hogy belepof: egy webes alkalmazas nem opcio? Ha nem, miert
> >>>> nem?
> >>>>
> >>>> Azert erdeklodok tisztelettel, mert egy csomo olyan framework van,
> >>>> ahol gyakorlatilag egy ilyen feladat implementalasa kimerul az IDE-vel
> >>>> torteno kodgeneralasban, illetve a HTML formok megdizajnolasaban.
> >>>> Legalabbis, a leirasodbol arra kovetkeztetek, hogy semmi bonyolultat
> >>>> nem kellene tudnia az alkalmazasnak, ha felmerult az APEX, mint
> >>>> implementacios platform.
> >>>>
> >>>> Egyebkent pedig szerintem databindinges ojjektumok (gridek pl)
> >>>> elerhetoek javahoz is, ha es amennyiben te es a fejlesztocsapat
> >>>> Javaban otthon erzitek magatokat, en nem feltetlen eroltetnek egy
> >>>> ennyire mas kornyezetet. Habar a C# szintaxisa hasonlit a Javaera, ez
> >>>> elmondhato barmely C szintaxisu nyelvre, megsincs ket egyforma
> >>>> kozottuk. A C# es a Java kozott igencsak nagy elteresek vannak.
> >>>>
> >>>> Raadasul itt felmerult a .Net framework kerdese is. Ha engem kerdezel,
> >>>> a 2.0 helyett ma mar legalabb 3.5-re kell targetalni, ha nem akarunk
> >>>> nagyon sok fejlesztoi eroforrast beleolni a projektbe, ugyanis a LINQ
> >>>> es a WPF viszonylag egyszeruve teszi a fejlesztest. Ezek nelkul ma mar
> >>>> szerintem elkepzelhetetlen egy adatokkal dolgozo .Net alkalmazas.
> >>>>
> >>>> Raadasul a .Net pont ugyanolyan nativ, mint a Java: semennyire.
> >>>>
> >>>> Egyebkent a listadat bongeszve folyamatosan az az erzesem, hogy te egy
> >>>> webes alkalmazast szeretnel fejleszteni, csak valamiert nem engedik
> >>>> neked.
> >>>>
> >>>> Garami Gábor
> >>>> E-mail: gabor.garami at hron.me
> >>>> Tel: +36 20 235 9621
> >>>> MSN: hrgy at vipmail.hu
> >>>> Skype: hron84
> >>>>
> >>>>
> >>>> 2013/2/2 Molnár Miklós <timortinj at freemail.hu>:
> >>>> > Sziasztok,
> >>>> >
> >>>> >
> >>>> >
> >>>> > Feladat: képernyőkön keresztül kell Oracle adatbázisba adatokat
> >>>> > rögzíteni
> >>>> > (+valamiféle menürendszer)
> >>>> >
> >>>> >
> >>>> >
> >>>> > Milyen technológiát tartotok erre legalkalmasabbnak egyértelműen
> csak
> >>>> > Windows alatt?
> >>>> >
> >>>> >
> >>>> >
> >>>> > Az APEX egy triviálisan létező lehetségesi opció erre (mivel Oracle
> >>>> > adott és
> >>>> > azon belül már ingyenes):
> >>>> >
> >>>> > Ami még eszembejut: Free Pascal + Lazarus kombó.
> >>>> >
> >>>> >
> >>>> >
> >>>> > Az én szempontjaim a választáshoz az alábbiak lennének:
> >>>> >
> >>>> > - NEM szempont tehát, hogy Linuxon és Windowson egyformán jó legyen:
> >>>> > elég a
> >>>> > Windows támogatása (100%-ban windows-gépeken történik a rögzítés).
> >>>> >
> >>>> > - Free/Open Source legyen a fejlesztő környezete (üzemeltetése)
> >>>> >
> >>>> > - Legkisebb "lábnyomú" (footprint), pehelysúlyú (lightweight)
> legyen:
> >>>> > gyors
> >>>> > indulású futtató-alkalmazás, kis méretű natív exe előnyben.
> >>>> >
> >>>> > - Minél könnyebb legyen benne fejleszteni: Java Swing és/vagy
> SWT-nél
> >>>> > egyszerűbben.
> >>>> >
> >>>> > - Minél teljesebb felhasználói élményt adjon rögzítői oldalon.
> >>>> >
> >>>> > - Szép legyen a form. Nálam a "szép form" a régi Delphis 3rdparty
> >>>> > bővítményes eszkökészlettel volt implementálható.
> >>>> >
> >>>> > - Billentyűzet-támogatás elegáns legyen (ne egerészni kelljen a
> >>>> > rögzítőnek).
> >>>> >
> >>>> > - Könnyű legyen módosítani a formokat, bővíteni
> >>>> > formokkal/alkalmazásokkal
> >>>> >
> >>>> > - Könnyű legyen üzemeltetni. Nálam a könnyű egy régi exe lecserélése
> >>>> > egy
> >>>> > újra például ;) És nem alkalmazás-szerver leállítása, újraindítása,
> >>>> > hibák
> >>>> > kezelése stb.
> >>>> >
> >>>> > - 64-bites natív támogatás (esetleg).
> >>>> >
> >>>> > - A fejlesztő környezet minél kevésbé legyen "egzotikus",
> abbahagyott
> >>>> > fejlesztésű, kevéssé dokumentált stb (esetleg).
> >>>> >
> >>>> > - Több db-platform támogatása (esetleg). Eddig 100%-ban Oracle-ben
> >>>> > volt/van
> >>>> > minden. De a kertek alatt most lopódzik be az MSSQL Server. Emiatt
> egy
> >>>> > APEX
> >>>> > nem feltétlen előny.
> >>>> >
> >>>> >
> >>>> >
> >>>> > Na és egyéb szempont technológia-választáshoz?
> >>>> >
> >>>> >
> >>>> >
> >>>> > Köszönettel:
> >>>> >
> >>>> > MM
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > Javalist mailing list
> >>>> > Javalist at lists.javaforum.hu
> >>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
> >>>> >
> >>>> _______________________________________________
> >>>> Javalist mailing list
> >>>> Javalist at lists.javaforum.hu
> >>>> http://lists.javaforum.hu/mailman/listinfo/javalist
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Javalist mailing list
> >>> Javalist at lists.javaforum.hu
> >>> http://lists.javaforum.hu/mailman/listinfo/javalist
> >>>
> >>
> >> _______________________________________________
> >> Javalist mailing list
> >> Javalist at lists.javaforum.hu
> >> http://lists.javaforum.hu/mailman/listinfo/javalist
> >>
> >
> >
> > _______________________________________________
> > Javalist mailing list
> > Javalist at lists.javaforum.hu
> > http://lists.javaforum.hu/mailman/listinfo/javalist
> >
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130202/1186a70f/attachment.html>