Selainpään toteutus JAVA:lla käyttäen Googlen GWT:tä

Hajanaisia muistiinponoja ekan proton teon aikana:

• XHR:stä pääsee vain responseTextiin käsiksi. Tuplaparsinta?

• tyypitetyssa kielessä XML-muotoisen UIDL-viestin käsittely entistäkin kankeampaa.

• Java-Eclipse yhdistelmällä on vaikea kirjoittaa rumaa koodia vaikka oikein yrittää :)

• debuggaaminen hosted-modessa (ei käännetty javascriptiksi) ei niin sujuvaa kuin toivoin
  • käynnistyslatenssi vs. Firefoxissa tehty reload
  • natiivit metodit
  • Painin xhr ongelmien kanssa ja oli vaikea löytää paikka jossa onglema tuli. Hosted modessakin ajetaan jotain javascriptiä (natiivit metodit).

• POSTaamisen kanssa tuntuu olevan isoja ongelmia. Voi kyllä olla että olin "jumissakin", mutta siihen uskoon jäin että homma kusee -> GET metodi variaabelien päivitykseen.

• pe 4.5. klo 1450 Tähän asti homma on ollut melko sujuvaa POSTaus ongelmia lukuunottamatta. Nyt rupesi kuitenkin jumittamaan reilusti. Tilanne:
  • Toteutettu, client päähän variaabelit(ja niistä vain Boolean) ja toiminnallisella tasolla Button, Label, OrderedLayout?, RootWindow?
  • testiohjelmassa button jonka napsautusten määrä päivittyy buttoniin ja yhteen labeliin
  • mitä käy: Safari, Firefox ja Opera rullaa hyvin, mutta markkinoiden YKKÖSSELAIN kusee versiolla kuin versiolla. ... alkanee tosi testi. Kuinka eka selainongelma ratkeaa? Olo erittäin aseeton.

• klo 15:30. Tällä kertaa ratkaisu oli helpohko. IE cachettaa get requestit. Lisäsin kasvavan id:n kaikkiin pyyntöihin. Lienee ollut joskus ongemaa Wanhassa clientissäkin kun käytti aikoinaan GET:tiä. Fundamentaalisestihan tämä on väärä tapa lähettää muuttuvaa tietoa, mutta kun POSTtausta en saanut kirveelläkään toimimaan

• Nyt täytyisi rakentaa silta vanhojen render funktioiden käyttöön.
  • tuntuu aika suurelta työltä ja huonolaatuisen koodin tukemisen takia lisäkoukkujen teko tuntuu hölmöltä
  • tässä kohtaa tekisi mieli rakentaa JsonPaintTarget? ja kokeilla rakentaa ScrollTable? JS oliona (vs. käyttää huonosti rakenteeseen sopivaan render-functiota. Sitä voisi sitten käyttää joko GwtClientistä? tai natiivista uudelleen kirjoitetusta JS clientistä
    • saisi käsitystä kuinka kauan uudelleenkirjoitus todella vie aikaa
    • työtä jatkoa varten joka tapauksessa

Huomioita pintapuolisen renderfunctioden porttaus tutkailun jälkeen:

• Java-JavaScript? kommunikointi on kankeaa:

   	var client = this.@com.itmill.gwtclient.client.LegacyClientWrapper::lClient;
  

• Tätä suurempi ongelma on täysin erilainen client puolen arkkitehtuuri.
• Ongelmia:
  • Gwt:n XML Node olion siirtäminen vanhalle render funtiolle
  • Vanhatkin komponentit täytyy pystyä GwtClientin? tapaan instantioimaan ja lisäämään toiseen (Tarvitaan wrapperit ja vaikka käytetään render functiota)
  • Container tyyppisten renderfunctioiden porttaaminen lienee varsin vaikeaa, koska renderfunktioista täytyy pystyä palauttamaan rendaus järkevästi Gwt:n puolellle. Ts. Lapsi componenttien rendaus täytyy palautua uudelle clientille vaikka container olisi vielä vanhaa koodia.
• aavistus: Vanhojen renderFunctioiden tukeminen GwtClientistä?, vaatii niin suuren työn että on nopeampaa kirjoittaa komponentit uudelleen
• Huomio: jos meidän komponentit olisi JS-puolella edes jonkinnäköisiä olioita, wrapperien tekeminen olisi paljon helpompaa.

18.5 : Toteutin Selectin _rendaamisen_ vanhalla renderFunctiolla.

• LegacyClientWrapper?-java luokka ja muunneltu client koodi.
• Parametrien lähetys (ts. selecti on "readOnly") ei toimine tai ainakin bugaa (ei mene GWT-clientin kautta)
• XML Node ongittu aika rumasti natiivissa functiossa.
  • Kokeilemalla etsin oikean muuttujan obfuskoidusta koodista
  • tartuntapinta eval:n kautta (muutoin GWT kääntäjä uudelleen nimeää muuttujan nimen)
  • muuttuu käytännössä jokaisella käännöksellä kun tehdään pienikin muutos
  • käytännössä pitäisi forkata GWT:n XML-parseri ja laajentaa rajapintaa functiolla joka palauttaa natiivin toteutuksen jsObject:in

Variaabelien käsittely täytyisi siis rakentaa/sillata ja ratkaista kuinka rendaus palautuu kontainereistä GWT koodiin.

VERSIO JS -> GWT

Tein JsonPaintTargetin? ja uuden clientin prototyyping javascriptillä talven suunnitelman tyyliin, suurin piirtein samaan vaiheeseen kuin GWT prototyypin. Tämän jälkeen protoilin GWT:llä tehtävän koodin liittämistä JS:lla tehtyyn ytimeen.

GWT:n JSNI on todellakin suunniteltu vanhan javascriptin liittämiseen uuteen GWT:llä tehtävään sovellukseen eikä päin vastoin. GWT:n javascriptit ajetaan omassa scopessa, joten GWT:n olioihin käsiksi pääseminen vaatii omaa kikkailuaan. Käytännössä GWT:n initialisoinnissa on luotava JS olio, johon ajon aikana asetetaan "proxy" functiot Toolkitissa (itmtk) tarvittaville functioille. Näin talteen jää siis tuo GWT:n closure ja functiot toimivat oikein. Tämä olio asetetaan johonkin josta teeman functiot voivat edelleen kutsua proxyn functioita. Proto nyt vaiheessa jossa lähettää takaisin palvelimelle asti tavaraa. Sen väsäämisessä sai hieman tuta gwt:n koodin kanssa tulevia paniikkitilantaita. Nyt niitä tuli selvästi enemmän kun käytin enemmän JSNI rajapintoja ja täysin ei tuettua closuren kaappausta. Risteyskodissa tulevia virheitä korjataan käytännössä kokeilemalla.

Jos JS-GWTJS aidan saa siivottua voi tämäkin ohjelmointimalli tulla mahdolliseksi, mutta käytännössä javascriptiä osaava halunnee tässä mallissa tehdä kaiken javascriptillä. Ja toisaalta jonkin verran natiivia javascriptiä joutuu joka tapauksessa kirjoittamaan (proxyn), vaikka suurimman osan komponentista pystyisikin tekemään javalla. Käytännössä siis tämä vaihtoehto tulisi lähinnä markkinamiesten pulinaksi "Code new components in Java!".

SUMMARUM

Jos GWT:n kanssa homma lähtee viemään:

• unohdetaan vanhat render funktiot kokonaan, käytetään korkeintaa ideoita komponenttien teosta
• kirjoitetaan kaikki Javalla niin pitkälle kuin mahdollista, JSNI käteen vain "hätätilanteessa". Liikkeelle kovasta päästä (scrolltable), jotta voi vetää hätäjarrusta jos homma ei pelaa.
• toivotaan että:
  • gwt hoitaa selainyhteensopivuusongelmat
  • gwt pitää kakun sen verran sutjakkaana että myös -removed- pyörii sillä
  • itmill toolkit toimii edelleen Reindeerissä

Jos päätös olisi mun, en lähtisi GWT:n kelkkaan. Tietenkin otettava huomioon että mulla oli ennakkoasennekin tämä. Yllättävän hieno kone se on ja valmiita GWT:n komponentteja käyttäessä sillä saanee nopeastikin joitain juttuja hoidettua. Ja sillä puhtaalla Javalla, joka Eclipsen kanssa pakottaa tekemään luettavaa koodia.

Puhtaan JS clientin puolesta (vs. GWT) puhuvia argumentteja:

• mahdollisuus valita ulkopuolinen JS-kirjasto (Dojo, YUI, ...) vapaammin, myös per teema. Ts. ei sitouduta yhteen JS-kirjastoon (jollaisena GWT:tä voi pitää)
• helpommin optimoitavissa, pienempi js koodi
• mahdollisuus selvittää selaintason ongelmat (ja sitäkautta ylläpitää nykyinen laaja selaintuki)
• mahdollisuus kopioida (copy-paste-kopioida) jonkin verran entisten komponenttien toteutuksia

Markkinoinnillisesti saattaisi olla hyvä veto tehdä teema jossa käytetään jotain monimutkaista gwt:llä tehtyä komponenttia. Tämän voisi periaatteessa tehdä 4.0.x sarjaankin, vaikka mallioliot omaavaan clienttiin olisi toki helpompaa. "Todistettaisiin" että Toolkitiin voi tehdä komponentteja myös GWTllä ja saataisiin toivonmukaan julkisuutta Toolkitille. Tämän suuntainen integraatio (JS -> GWT JS) olisi myös sellaista jota on vähän (lainkaan?) tehty muualla, joten julkisuus saattaisi olla ihan oikeasti mahdollista.