Moi kaikki JavaGurut,
Olen tuossa hieman funtsinut sitä, että millä tekniikalla serverillä sijaitseva hakemistopuu kannattaisi siirtää applettiin. Nähdäkseni toimivia tapoja on ainakin kolme: XML, JTree serializable-rajapintaa käyttäen ja oma tekstipohjainen formaatti. Viimeksimainittu ei oikein sykähdytä, joten olen miettinyt noita kahta ensinmainittua ns. käytännön vaihtoehtoina.
XML:n etuna olisi moduulien välisen Java-sidonnaisuuden poistuminen, mutta samalla ohjelman kompleksisuus kasvaa luonnollisesti hieman, koska serverin päässä hakemistopuusta pitää ensin muodostaa XML-rakenne, joka sitten siiretään applettiin. Appletissa tästä XML:stä pitää edelleen muodostaa JTree, jotta se voidaan esittää käyttäjälle visuaalisessa muodossa. (Serializable-menetelmällä tämä XML-konversio jää pois välistä, joten sen käyttö hieman houkuttaa.)
Koko pakkaa sekoittaa vielä se, että virhetilanteessa palautetaan virheilmoitus esim. juuri hakemistopuun sijasta, jolloin voi muodostua mielenkiintoisia konversio-ongelmia...
Serializable-menetelmää käyttäen nämä ongelmat voidaan taklata luomalla siirtoa varten oma datan siirtoluokka (implements Serializable), joka kuvaa siirrettävän datatyypin esim. getType()-metodissaan ja saataisiin ulos getObject()-metodilla. Hmm, Onkohan muuten tuo Object-kantaluokka sarjoittuva, eli voiko tälläistä siirtoluokkaa edes tehdä?!?
XML:stä mulla ei ole juurikaan kokemuksia, joten en tiedä miten XML:ssä hoidetaan nuo poikkeustilanteet. Tai onkohan siihen mitään fiksua menetelmää ensinkään?
Avusta ja kommenteista kiittäen,
Jonttu
Olen tuossa hieman funtsinut sitä, että millä tekniikalla serverillä sijaitseva hakemistopuu kannattaisi siirtää applettiin. Nähdäkseni toimivia tapoja on ainakin kolme: XML, JTree serializable-rajapintaa käyttäen ja oma tekstipohjainen formaatti. Viimeksimainittu ei oikein sykähdytä, joten olen miettinyt noita kahta ensinmainittua ns. käytännön vaihtoehtoina.
XML:n etuna olisi moduulien välisen Java-sidonnaisuuden poistuminen, mutta samalla ohjelman kompleksisuus kasvaa luonnollisesti hieman, koska serverin päässä hakemistopuusta pitää ensin muodostaa XML-rakenne, joka sitten siiretään applettiin. Appletissa tästä XML:stä pitää edelleen muodostaa JTree, jotta se voidaan esittää käyttäjälle visuaalisessa muodossa. (Serializable-menetelmällä tämä XML-konversio jää pois välistä, joten sen käyttö hieman houkuttaa.)
Koko pakkaa sekoittaa vielä se, että virhetilanteessa palautetaan virheilmoitus esim. juuri hakemistopuun sijasta, jolloin voi muodostua mielenkiintoisia konversio-ongelmia...
Serializable-menetelmää käyttäen nämä ongelmat voidaan taklata luomalla siirtoa varten oma datan siirtoluokka (implements Serializable), joka kuvaa siirrettävän datatyypin esim. getType()-metodissaan ja saataisiin ulos getObject()-metodilla. Hmm, Onkohan muuten tuo Object-kantaluokka sarjoittuva, eli voiko tälläistä siirtoluokkaa edes tehdä?!?
XML:stä mulla ei ole juurikaan kokemuksia, joten en tiedä miten XML:ssä hoidetaan nuo poikkeustilanteet. Tai onkohan siihen mitään fiksua menetelmää ensinkään?
Avusta ja kommenteista kiittäen,
Jonttu
Vastaukset 3
Vanhimmat
Hello Jonttu,
En ole itse tehnyt juurikaan Appletteja, mutta XML/DOM:n pyörittämisestä löytyy kyllä enemmän kokemusta.
DOM-Perussääntö I: DOM API on aika kankea. Mikäli haluat tehdä sen kanssa töitä, niin hanki joku työkalukirjasto, jolla "tree traversal" helpottuu.
DOM-perussääntö II: DOM-Document:it ovat hitaita ja raskaita. Tämä johtuu lähinnä siitä, että jokaista Nodea kohden luodaan uusi luokan ilmentymä. Jos hakemistojen lukumäärä on koko ajan hallinnassa, eikä Nodejen määrä kasva kovin moneen sataan, niin mikäs siinä..
Mikäli haluat hallita laajaa hakemistopuuta, niin ehkä XML kannattaa unohtaa, ainakin mitä tulee DOM:iin. SAX on hieman kevyempi vaihtoehto.
Vielä yksi pointti: Niin viheliäistä kun DOM API:n kirjoittaminen onkin, sen osaamisesta on ollut itselleni tavattomasti hyötyä :) Kaikki "talon softat" tehdään nykyään sillä (pitäen tietysti mielessä säännöt I ja II).
..kannattaa varmaan laittaa hieman lisää paukkuja tuon XML:n ja Javan parsereiden (DOM/SAX) tutkailuun, kun tää homma haiskahtaa mitä ilmeisimmin XML-caseiltä.
Monta kertaa homma on muuten just niin, että se "helpoin" tie muuttuu ennenpitkää aika kivikkoiseksi ja näin voi käydä myös tuossa sarjoitusjutussa. Toisaalta täydellistä systeemiä ei olekkaan, joten joskus hommat pitää vaan saada rulaamaan tietyssä ajassa ja varautua siihen, että porukat listii valinnan tehneen arkkitehdin kuitenkin. Kysymys onkin lähinnä siitä, että kuinka nopeasti tämä tapahtuu? ;) (Ei vais, sen verran pitää olla kunnianhimoa, että luotu arkkitehtuuri palvelee päivästä toiseen vaikka kuoret ympärillä vaihtuisivatkin-kö?!?).
Just juu, kävin tässä kirjoittamisen lomassa kurkistamassa tuota Java Tutoriaalia kohdasta "XML and the Document Object Model" ja ei se niin kauhean monimutkaiselta loppujen lopuksi näytäkkään. Valmista työkalua on kivasti tarjolla jopa niin, että XML-mällistä saa JTreen suht' helposti... Taitaa tuo ikä vaan alkaa tekemään tepposia, kun kaikki uusi ensialkuun tuottaa niin paljon vastareaktioita.
Hmmm, tähän asti olemme keskustelleet lähinnä hakemistopuusta, jonka yhtenä pointtinasi oli DOM:n raskaus suurempien tietomäärien esitystapana. Entäpä, jos siirrän koko systeemin XML-pohjalle niin miten hyvin ko. tekniikka selviytyy tilanteessa, jossa esimerkiksi muutaman sadan tietokantatietueen tiedot (10-20 kenttää/tietue) muunnetaan DOM-mallin mukaiseen muotoon ja esitetään käyttäjälle ymmärettävässä muodossa (JTree, jne)? - Varmaan hirveän vaikea estimoida tuota asiaa, mutta karkea arvauskin on tyhjää parempi. Meneeköhän prosessointiin millisekuntteja, sekuntteja vai koko kahvitauko?
Nykyisellään käytän datan esitysmuotona avain/arvo-pareihin sidottua text-pohjaista simppeliä esitystapaa, jonka nopeus tässä tapauksessa on noin ruutitynnyrin luokkaa, mutta siinä on kyllä hieman varaa löysätäkkin, jos "jatkuvuus" ja "universaalisuus" olisi paremmin hyppysissä. Eikös se menekkin niin, että konetehot senkuin vain kasvaa, jolloin hitauskriittisyys poistuu itsekseen ajan myötä ja kauaskantoisuus alkaa tuottaa hedelmää tyyliin "Time is on My Side".
Jonttu
Kokeile ihmeessä tuota XML-versiota, onnistunee vanhalta tekijältä päivän tai parin urakoinnilla.
Suorituskyvystä: kovin hankalan kysymyksen pistit. Eiköhän tuollainen datamäärän käsittelynopeus ole vielä ihan siedettävä - ehkä puoli sekuntia. Mikäli tuntuu kovin hitaalta, voit myös kokeilla vanhaa temppua: Älä tee XML-puuta Document:ina, vaan kasaa se StringBufferiin "manuaalisesti" tietokannasta lukemisen yhteydessä. Syntyneen StringBufferin voi aina jälkeenpäin muuttaa DOM:ksi, jos on tarvetta.