[Javalist] Form & DB

2013. Feb. 2., Szo, 23:31:30 CET

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
>
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130202/5bb215e5/attachment.html>