Érdemes-e Javara szakosodni
2005-05-05T16:55:00+02:00
2005-06-27T15:34:17+02:00
2022-07-27T01:51:09+02:00
  • Kiegészítve LC hozzászólását.
    1., Meghatározott jelölés rendszere van, amit mindenki úgy ért, ahogy kell.
    2., Nekem ákom-bákomokkal szórakoznod, hanem a szerkesztő megoldja.
    3., Könnyebb javítani, mintha papíron csinálod.
    4., Az UML ábrázolás többféle diagramokból áll. Mindegyiknek megvan a létjogosultsága. Éppen ezért tudja a fejlesztő implementálni.
    5., OO alapú fejlesztéshez van, de nyelvtől független.
    6., A jobb eszközökből a kép formátumon kívül szabványos formában kinyerhető amit készítettél, így lehetőség van újrahasznosítani és könnyen módosítani.
    7., Amit én még fontosnak tartok, hogy azt érdemes használni, ami jobbá, könnyebbé, dokumentáltabbá és gyorsabbá teszi a fejlesztésedet.
    8., Hogy ne csak feleslegesen készítsd a diagramokat, a jobb alkalmazásokhoz található különféle kódgenerátor, amelyek a struktúrát és az osztályok deklarációit legenerálják, így neked csak az egyes metódusok megvalósítását kell implementálnod úgy, hogy meg vannak adva a kellő paraméterek és visszatérési értékek.

    Most csak ennyi jutott az eszembe.

    Üdv: Webappz
    Mutasd a teljes hozzászólást!
  • Unifided Modelling Language. Az objektumok grafikus ábrázolásának mára már szabvánnyá vált módja, az OO tervezés alapja. Sok jó könyv szól ilyesmiről, a legtöbb mai CASE eszköz (Computer Aided System Engineering) is ezt támogatja, ilyen Pl. az ArgoUML és attól felfelé minden.
    Nem feltétlenül szükséges, de mára azért nem árt ha megtervezed a dolgokat mielőtt nekiállsz kódolni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Felmerült itt egy ujabb kérdés.
    UML?
    Ki ez, mi ez? Mire kell stb stb...
    Feltétlenül szükséges?
    Mutasd a teljes hozzászólást!
  • Szevasztok!

    Izgalmas a téma számomra is. Néhány napja kezdtem el kacsingatni az EJB irányába én is. Most jutottam el odáig, hogy a JSF alkalmazza a J2EE-t (Manning, JSF in action erre vonatkozó fejezete).
    Rögtön egy csomó kérdés/gond merült fel bennem, legyetek szívesek kijavítani, ill. tanácsot adni.

    A felhasznált fejlesztői környezet és JDK az én értelmezésem szerint elég macerás. A JBuilder 2005 Dev-et használom, de ez nem támogatja a J2EE-t. Nekiestem a Sun-nak, nosza letöltöm ezt. Teljesen megdöbbentem, amikor olvastam, hogy ez NEM használható fel termelő környezetben, csak oktatásra. A legolcsóbb eszköz amit találtam ehhez az IBM-től a Websphere Site Developer, de ez is 300 kHuf körül van, amennyiben van valami alap.
    Várom a véleményteket, üdv: Karcsi
    Mutasd a teljes hozzászólást!
  • Szeretném megkérdezni,hogy szervlet,jsp ilyesmik után mi a következő lépés?
    Vagyis merre lehet tovább lépni,ezután már jöhet ilyen,hogy EJB vagy az még korai...
    Természetesen nem állitok olyat,hogy akár szervletből akár JSP-ből full-progi vagyok,bőven van mit tanulnom.
    Csak érdeklődőm.
    Mutasd a teljes hozzászólást!
  • Amelyik szimpatikusabb. En speciel NetBugsot hasznaltam, de nehany honapja lett levaltva Gel-re. Igaz, h fele annyit nem tud, mint a Netbeans, de legalabb gyors. :) Ja, es ami szamomra egy fontos szempont: nativ.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Szeretném megkérdezni,hogy szervlet,jsp ilyesmik után mi a következő lépés?
    Vagyis merre lehet tovább lépni,ezután már jöhet ilyen,hogy EJB vagy az még korai...
    Természetesen nem állitok olyat,hogy akár szervletből akár JSP-ből full-progi vagyok,bőven van mit tanulnom.
    Csak érdeklődőm.
    Egyébként melyiket szokás használni Netbeans vagy Eclipse, nekem jobban tetszik a Netbeans,de az Eclipse-vel sincs bajom,csak épp nem tudok dönteni.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Szeretném megkérdezni,hogy szervlet,jsp ilyesmik után mi a következő lépés?
    Vagyis merre lehet tovább lépni,ezután már jöhet ilyen,hogy EJB vagy az még korai...
    Természetesen nem állitok olyat,hogy akár szervletből akár JSP-ből full-progi vagyok,bőven van mit tanulnom.
    Csak érdeklődőm.
    Egyébként melyiket szokás használni Netbeans vagy Eclipse, nekem jobban tetszik a Netbeans,de az Eclipse-vel sincs bajom,csak épp nem tudok dönteni.
    Mutasd a teljes hozzászólást!
  • Nahát, milyen meglepetés! Már fent van néhány napja a 4.1-es Netbeans a gépen, de csak most jutottam el odaáig, hogy ebben van vizuális web.xml szerkesztő, amellyel nagyon egyszerűen lehet az összes mappinget, parametert es szervletet nyomon követni.
    Mutasd a teljes hozzászólást!
  • - Flowchart keszitesre vannak dolgok.

    - a servlet-eket altalaban ertelmes nevvel szoktak jelolni, hogy a nevuk alapjan is lehessen tudni hogy milyen servlet-re mappelsz.

    - wysiwyg jsp szerkesztes... utobbi idoben nem editaltam jsp-t, de van a myeclipse-ben is jsp editor, a webtools projectben is, meg meg van egy par... korabban viszont a homesite 4.52-ot hasznaltam ami nem wysiwyg viszont kellemes es gyors.. az 5-os vagy mx verzio talan mar wysiwyg is...



    Mutasd a teljes hozzászólást!
  • A web.xml-nek nem a szerkesztesevel van a baj, hanem az atlathatosagaval. Konkretan: a servlet-class és az url-mapping nincs egy helyen, nem derül ki első pillantásra, hogy az url-mappingok milyen servleteket hívnak meg. Erre jönne jól egy flowchart készítő plugin. Legalábbis nekem hiányzik.

    Tényleg Ti mit használtok wysiwyg jsp-szerkesztésre? Én Dreamweavert, ami nem egy rossz program, csak sajnos nem fejlesztőeszköz, és a jsp-t különösen utálja. Nincs ennél jobb megoldás? MyEclipse? PinEdit?
    Mutasd a teljes hozzászólást!
  • A Netbeans 4.1 (EA) elvileg J2EE-re is ki van hegyezve, érdemes az ismertetőjét elolvasni. (Bár a konfigurációs fájlok külön-külön tényleg nem bonyolultak, de egyszerűbb az élet ha vmi integrált módon tudod kezelni őket.)

    Apache NetBeans archive
    Mutasd a teljes hozzászólást!
  • netbeans-t nem ismerem.

    web.xml annyira egyszeru meg minimal dolog, hogy ahhoz nem kell faramuci szerkeszto, normalis ember kezzel editalja. de nekieshetsz xml szerkesztokkel azzal Dunat lehet rekeszteni.

    Minden egyebre biztosan talalsz megfelelo eszkozt.
    Mutasd a teljes hozzászólást!
  • Minden celra a megfelelo eszkozt.


    Na jó akkor konkrétabban teszem fel a kérdést. Van vizuális web.xml szerkesztő vagy legalább böngésző eszköz? Lehetőleg netbeans plugin?
    Mutasd a teljes hozzászólást!
  • Minden celra a megfelelo eszkozt.

    Nyugodj meg, mindent amit php-ban meg lehet csinalni, azt Java-ban is meg lehet.
    Mutasd a teljes hozzászólást!
  • tod van egy olyan pattern hogy front controller, amit a jelenlegi model2 framework-ök többsége is használ.
    ennek ismeretében a filter az nagyon jó helyen van.


    Van. Es erre altalaban servlet-et hasznalnak, mert annak az a dolga, hogy a request-et lekezelje. Ha egyszer ez a servlet az egyeduli belepesi pont a server oldalra, akkor nincs szukseg filterre, ami azt csinalja, hogy a sok belepesi pontodra rakenyszeritsen valamit. Minek legyen sok belepesi pont?

    Mit csinaltal volna egy olyan Servlet Devkit-ben ahol meg nincs filter? 1 szervletet.

    Meg tudod csinalni itt is? Meg. Akkor ez egy jo megoldas. Miert kell masikat keresni ami csak szukebb kornyezetben mukodik?

    Emiatt tovabbra is azt mondom, hogy a filter hasznalata arra a celra egy tuneti kezeles, url-eket iratsz at vele, mikor az url-eket is te generalod. Miert nem generalod az url-eket eleve jol?



    Mutasd a teljes hozzászólást!
  • UML szerkesztők tudják a request-adogatás útvonalát is

    Elvileg bármit le lehet modellezni. Pl: szekvencia vagy együttműködés diagrammal

    de ha utólag át kell alakítani néhány dolgot, vagy hozzá kell illeszteni valamit, komoly hátrány, ha a rendszerterveket meg UML-diagrammokat kell böngészni

    Pedig pont az ellenkezője miatt lett kitalálva. Szvsz csak megszokás és főként _gyakorlat_ kérdése.

    Érdemes fejlesztőeszközbe integrált UML toolt használni.
    Mutasd a teljes hozzászólást!
  • Igen, de az UML szerkesztők tudják a request-adogatás útvonalát is modellezni? Ismerik az url-patterneket is?

    Azt értem, hogy először a specifikáció, meg a use case-ek, a rendszertervek, az UML-ábrák és az azokból legenerált kód, de a legtöbb internetes projektnél minderre nincs idő. Ez az oldal például néhány nap alatt készült el php/mysql-ben adminisztrációs felületekkel együtt, és gondolom, ez java-ban sem lenne másképpen, de ha utólag át kell alakítani néhány dolgot, vagy hozzá kell illeszteni valamit, komoly hátrány, ha a rendszerterveket meg UML-diagrammokat kell böngészni. Ez komoly hátrány mondjuk a php-vel szemben, még akkor is, ha javahoz sokkal komolyabb fejlesztőeszközök vannak (ami viszont egy komoly előny).
    Mutasd a teljes hozzászólást!
  • A rendszertervemben van egy nagy papír, ahová lerajzoltam folyamatábra-szerűen az összes szervletet és jsp-t, de hogyan lehet mindezt automatizáltan, a forráskódból visszafejtve kirajzoltatni valamilyen UML diagramm-szerűen?


    Célszerű lenne fordítva. Egy UML modellezővel tervezed meg a programot, ami legenerálja a JAVA kód vázát. Így remekül átlátható programot lehet készíteni.
    Mutasd a teljes hozzászólást!
  • Egyaltalan miert erdekes hogy baratsagos legyen?


    Sziasztok.
    Nekem az a problémám, hogy egy MVC java alkalmazásban hogyan lehet fejlesztés közben vagy utólag könnyen (grafikus formában) átlátni, hogy merre mennek a requestek? Hogy ne kelljen a web.xml-t, és a szervletek forráskódját böngészni, ha valamit nem találok? A rendszertervemben van egy nagy papír, ahová lerajzoltam folyamatábra-szerűen az összes szervletet és jsp-t, de hogyan lehet mindezt automatizáltan, a forráskódból visszafejtve kirajzoltatni valamilyen UML diagramm-szerűen? Nekem eddig az átláthatóság a legnagyobb problémám a java projektekkel, pedig a legnagyobb java programom, amelyet eddig fejlesztettem, csak kb. 5 adattáblát, 10-15 szervletet és objektumot, illetve 30-40 jsp-t tartalmaz (egy könyvtári rendszer és adminisztrációs felületei).
    Mutasd a teljes hozzászólást!
  • eselye se legyen egy JSP lapnak request feldolgozasara, es legjobb, ha a request parametereket nem is hasznalod benne. Akkor legalabb teljesen izolaltan cserelheto a JSP mas megjelenitesi technologiara.


    attól hogy url-ként akármi.jsp-t írok, az nem jelenti azt, hogy ne használhatnék más megjelentítési technikát. csak át kell alakítani a filtert (és csak ezt az egy filtert!).

    A filteres megoldas akkor is egy tuneti kezeles, amire semmi szukseg, ha a request-ek egyenesen maguktol egy servlet-hez mennek, mert arra vannak mappelve.


    tod van egy olyan pattern hogy front controller, amit a jelenlegi model2 framework-ök többsége is használ.
    ennek ismeretében a filter az nagyon jó helyen van.

    Mutasd a teljes hozzászólást!

  • nézd, ez megoldás attól még nem lesz model1 hogy a kérés a jsp-hez megy, hisz a filter minden *.jsp kéréskor közbelép.
    persze vannak ennek is hátrányai elismerem, de az sokat számít hogy a user egy barátságos jsp-re végződő url-t kap, és nem azt hogy servlets/izévalami


    ???

    1. Miert lenne egy .jsp kiterjesztes baratsagos? Egyaltalan miert erdekes hogy baratsagos legyen? Senki nem szokta az url-t nezegetni olyan igennyel hogy baratsagos legyen. Egyaltalan aki az url-t nezi, az meg ugyis mar altalaban ert hozza, es azert nezegeti hogy milyen parameterek maszkalnak. Azt meg mar nem erdekli hogy baratsagos, vagy sem.

    2. Ha baratsagosat akarsz, akkor legyen .html, az is teljesen egyszeruen megoldhato. De eselye se legyen egy JSP lapnak request feldolgozasara, es legjobb, ha a request parametereket nem is hasznalod benne. Akkor legalabb teljesen izolaltan cserelheto a JSP mas megjelenitesi technologiara.

    3. A servlets/...-t azt irtam, hogy felejtsd el. Csak a lustasag indokolja es security hole-t tesz lehetove, ha masban is lusta a user.

    4. A filteres megoldas akkor is egy tuneti kezeles, amire semmi szukseg, ha a request-ek egyenesen maguktol egy servlet-hez mennek, mert arra vannak mappelve.
    Mutasd a teljes hozzászólást!
  • nézd, ez megoldás attól még nem lesz model1 hogy a kérés a jsp-hez megy, hisz a filter minden *.jsp kéréskor közbelép.
    persze vannak ennek is hátrányai elismerem, de az sokat számít hogy a user egy barátságos jsp-re végződő url-t kap, és nem azt hogy servlets/izévalami.

    Sot mi tobb, eleve egy security hole lehetoseget veti fel, ha jsp-ket kozvetlen el tudsz erni kintrol, nem pedig csak a request leellenorzese utan, ha a jsp-k ellenorizetlenul hasznalnak request parametereket.


    ahogy mondtam, a request paramétereket a filter azonnal lepasszolja a lap szervletjéhez, a jsp nem kap ellenőrizetlenül semmit.

    Masik dolog, hogy felesleges minden kododat servlet-be tenni. Minek? Barmilyen mezei osztaly jo. Kell egy szervlet ami tovabbadja a hivasokat. Igy nem kell minden egyes szervletet betenni a web.xml-be


    nem is teszek ilyet. a szervleteim valójában mezei objektumok, amelyek implementálnak egy, a dologic-ot tartalmazó interfészt.

    Harmadik: minek framework nelkul? Ez elegge egy vaskalapos megoldasnak tunik. Ha van egy a celjaidnak megfelelo framework, hasznalni kell. Ha nincs, irni kell egyet. :) Ellenkezo esetben kodot duplikalsz, ami meg felesleges gepeles, es a karbantarthatosagot csokkenti.


    én ezzel csak boci architekúrális bizonytalanságát akartam eloszlatni.
    szerintem ő még nem tart ott, hogy framework-öt használjon.


    Mutasd a teljes hozzászólást!

  • mindenesetre én úgy csinálom, hogy amikor jön a request egy akármilyen jsp lapra, aktivizálódik egy filter, amelynek az a feladata hogy egy, a jsp lap nevével megegyező szervletet elindítson, és annak dologic(request, response) metódusát meghívja.


    Rossz az alapvetes!!! Mi koze a jsp-nek a request-hez????

    A bongeszonek total lenyegtelen hogy egy http kereset ki szolgalja ki.

    A JSP-nek meg semmi szuksege a request parameterekre.

    A request-et eleve egy servlet-re kell iranyitani, az majd tovabbadja annak az osztalynak akinek kell, nem pedig filterekkel szorakozni.

    Az elvegzi az alapjan amit kell. Ha adatvaltoztatast csinalt (amit nem jo ha refresh-elni tud), akkor eredmenynek kuld egy redirect-et (HTTP 302/303), ha sima GET volt aminek az a dolga hogy egy lapot leszedjen a bongeszonek, akkor meg forward-ol a JSP osztalynak. Amire a JSP-nek szuksege van, azt elhelyezi a request attributumakent.

    Ezaltal a JSP teljesen mar csak megjelenito retegkent funkcional.

    El kell szakadni attol a hibas prekoncepciotol, hogy az url-eknek, a megjelenito technologianak, es a kiterjeszteseknek barmi kozuk kene legyen egymashoz, igy ha valamit megjelenitunk annak a megjelenito technologianak megfelelo kiterjesztest adjuk.

    Ezeknek valojaban semmi koze egymashoz.

    A bongeszonek az szamit hogy a content-type passzoljon a generalt tartalomhoz illetve esetleg a tartalom mint adat formatuma passzoljon az url kiterjeszteshez hulye bongeszoknel.

    De semmi nem indokolja, hogy minden url-unk amit hasznalunk, az a megjelenito technologiara utaljon.

    Sot mi tobb, eleve egy security hole lehetoseget veti fel, ha jsp-ket kozvetlen el tudsz erni kintrol, nem pedig csak a request leellenorzese utan, ha a jsp-k ellenorizetlenul hasznalnak request parametereket.

    Egyszerubb ha erre lehetoseget sem adsz, az altal, hogy minden view leiro oldalt, legyen az jsp lap, velocity template, vagy barmi, a WEB-INF ala pakolsz, hogy csak forward-olni lehessen ra, de kintrol kozvetlenul elerni nem.

    Igy egyreszt tudsz egy ellenorzesi lehetoseget kikenyszeriteni, masreszt eleve a request parameterek jsp-beli hasznalatatol is eltantoritod a fejlesztot, mivel minek szorakozzon vele, ha servlet-ben (vagy barmi mas controller-beli kodban), Javaban is csinalhatja.

    Szoval el kene szakadni attol hogy hogy kenyszeritsuk ki azt, hogy a jsp-re mutato request mashova keruljon. Eleve ne mutasson, ne mutathasson jsp-re request.

    Masik dolog, hogy felesleges minden kododat servlet-be tenni. Minek? Barmilyen mezei osztaly jo. Kell egy szervlet ami tovabbadja a hivasokat. Igy nem kell minden egyes szervletet betenni a web.xml-be sem. Azzal meg ne gyere, hogy ServletServlet (/servlets/osztalynev formaju url-ek), mert az szinten egy security hole lehet, hogy barmilyen servlet-re ra tud hivni, akkor is ha nem is a megfelelo a session allapota...

    Harmadik: minek framework nelkul? Ez elegge egy vaskalapos megoldasnak tunik. Ha van egy a celjaidnak megfelelo framework, hasznalni kell. Ha nincs, irni kell egyet. :) Ellenkezo esetben kodot duplikalsz, ami meg felesleges gepeles, es a karbantarthatosagot csokkenti.
    Mutasd a teljes hozzászólást!
  • meglehetősen nehéz ügy sima jsp/servlet-ben különválasztani a feladatköröket.

    mindenesetre én úgy csinálom, hogy amikor jön a request egy akármilyen jsp lapra, aktivizálódik egy filter, amelynek az a feladata hogy egy, a jsp lap nevével megegyező szervletet elindítson, és annak dologic(request, response) metódusát meghívja.
    ezután ez a servlet felelős az üzleti logikát tartalmazó objektumaim meghívásáért, és az üzleti objektumok request/session/application scope-ba pakolásáért.
    miután ezt megtette, elforwardol a hozzá tartozó jsp-hez, ami szépen megjeleníti a scope-ba pakolt cuccokat.

    szal kész kínszenvedés, de meg lehet ezt framework nélkül is csinálni.
    Mutasd a teljes hozzászólást!

  • Akkor miért a JSP-ben van <jsp:useBean...>?


    Az arra van, hogy deklaralj egy Javabean-t aminek a property-jeihez hozzafersz.

    Metodushivast senki nem emlegetett.

    Uzleti metodus hivast, illetve eroforras elerest plane nem. Ezeket nem is nagyon szabad, ugyanis a JSP hibakezelesi lehetosegei korulbelul a nemletezovel versenyeznek, kenyelmessegben pedig az otos metroval. Raadasul hiba eseten a response mar meg van kezdve, igy nehez teljesen mas helyre forwardolni, ha esetleg mar flusholva is van. Valamint egy jsp lapon nem tudod, hogy az a lap a teljes response-t generalja, vagy csak egy reszet... Emiatt jobb, ha nem tortenhet hiba jsp lapon hasznalt dolgokban. Akkor nem kell jsp-be control jellegu funkcionalitast csinalni (mint hibalekezeles).
    Mutasd a teljes hozzászólást!

  • egyre többet hallom tőled a "kell" szót. java-ban nincs olyan hogy ezt így kell csinálni, mindenre több féle megoldás is létezik.
    neked az a dolgod, hogy ezekből kiválaszd a megfelelőt, időt költséget és egyebeket mérlegre téve.
    Mutasd a teljes hozzászólást!

  • Itt részletesen le van írva
    Akciós ár: 4700 Ft

    Mutasd a teljes hozzászólást!
  • Szervletből kell meghivni?
    Akkor miért a JSP-ben van <jsp:useBean...>?
    Mutasd a teljes hozzászólást!
  • Ez igy szigoruan veve hulyeseg. Az a javabean amit a weben informacioszolgaltatasra hasznalsz, magaban ne tartalmazzon logikat.

    Az enterprise javabean az amirol az emlitett helyen de legalabbis a kontextusaban szo lehetett. Azoknak viszont, mint emlitettem, semmi koze a javabeanekhez.

    Az uzleti logikat is teheted Javabean-ekbe (az is csak egy objektum), akkor viszont az kozelebe ne menjen a jsp-knek (vagy mas megjelenitesi technologianak), hanem a servletbol kell hivni.
    Mutasd a teljes hozzászólást!
abcd