[Javalist] Form & DB

2013. Feb. 2., Szo, 23:40:04 CET

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