Lomaopinnot: JSF 2.0 + PrimeFaces 3.0

(Kopio eri taustaisille kollegoille lähetetystä sähköpostista.)

Hei, katselin loman aikana erilaisia teknologioita, joista yksi oli JSF 2.0 + PrimeFaces 3.0 RC2.

Java Server Faces on selainteknologiastandardi, joka tuo yhteen web-käyttöliittymäsuunnittelijat, backend-kehittäjät sekä kolmannen osapuolen komponenttikirjastojen toimittajat. Se standardoi eri toimijoiden väliset rajapinnat, sekä web-sovelluksen teknisten toimijoiden osuudet sovelluksien käytön elinkaaren aikana. Siitä on useita implementaatioita.

PrimeFaces on komponenttikirjasto, joka sisältää kaiken mitä B2B web-sovellukset yleensä tarvitsevat, helppokäyttöiseksi paketoituna.

Nämä teknologiat kilpailevat perinteisen HTML/JavaScript käsin kehityksen kanssa, sekä sovelluskehittimistä MS:n webbikehittimen, sekä esimerkiksi Google Web Toolkitin, Vaatimen, ExtJS:n, SmartClientin, SmartGWT:n ja ExtGWT:n kanssa. (Uutena mutta varteenotettavana kilpailijana kentällä on 2012 dust.js:n tyyppiset teknologiat, joita mm. LinkedIn on siirtymässä käyttämään, REST JSON-palveluiden kanssa.)

JSF-sovellukset koostuvat näkymätemplateista (Facelets) joissa HTML-koodin seassa määritellyt näkymäkomponenttien instanssit osoittavat sovelluksen taustaosioon, eli beaneihin (tiettyä sopimusta noudattava Java-luokka) jotka on annotoitu JSF:n kontekstitiedolla. Tyypillisessä sovelluksessa on joitakin taustaluokkia joiden elikaari kuuluu sessiokontekstiin, joitakin taustaluokkia jotka elävät spesifisessä keskustelukontekstissa (esim. jos sovelluksessa on osioita joiden halutaan toimivan samaan aikaan saman selaimen eri tabeissa) tai jopa yhden requestin eli HTTP-pyynnön pituisessa kontekstissa.

(JSF 2.0:n sisäänrakennettu keskustelukonteksti toimii hyvin epäintuitiivisesti, ja sitä varten Apache MyFaces CODI projekti on luonut standardia noudattavan custom scopen, joka toimii fiksummin. CODI:n käyttöönotto vaatii vain sen, että otat sen kirjastot mukaan projektiin, ja merkkaat taustapavun sen keskustelukonteksti-annotaatiolla.)

Hyvä esimerkki JSF 2.0 toimintaperiaatteesta löytyy PrimeFaces ajax multiupload demosta, http://www.primefaces.org/showcase-labs/ui/fileUploadMultiple.jsf

<h:form enctype="multipart/form-data">  
    <p:fileUpload fileUploadListener="#{fileUploadController.handleFileUpload}"
            mode="advanced" update="messages" multiple="true" sizeLimit="100000"
            allowTypes="/(\.|\/)(gif|jpe?g|png)$/"/>  
    <p:growl id="messages" showDetail="true"/>  
</h:form> 

Taustapapu:
 
public class FileUploadController {  
    public void handleFileUpload(FileUploadEvent event) {
        FacesMessage msg = new FacesMessage("Succesful", event.getFile().getFileName() + " is uploaded.");
        FacesContext.getCurrentInstance().addMessage(null, msg);
    }
}

Tässä esimerkissä ajax-komponentti uploadaa tiedostot, ja sen jälkeen päivittää dynaamisesti "messages" komponentin, jonka tehtävä on näyttää pienessä viestilaatikossa eventtinotifikaatioita. Jos metodissa tiedostot laitettaisiinkin talteen keskusteluskooppiseen papuun, johon vaikkapa esikatselukomponentti puolestaan osoittaisi, senkin voisi laittaa automaattisesti päivittymään, ja kokonaisuus toimisi edelleen odotetulla tavalla, vaikka komponenttien ja taustadatan vuorovaikutus ei ole mitenkään yksinkertaista.

Tässä mallissa kontrolli säilyy palvelinpäässä, kun taas kilpailevassa GWT-mallissa sovellus pyörii itsenäisesti selaimessa, ja tekee vain spesifisiä pyyntöjä taustapalveluihin. Siinä missä käsin koodattavissa järjestelmissä rajapinnat rakennetaan joko REST JSON tai XML päälle, tai enterprise architectien toiveesta SOAP:illa, JSF komponenttikirjastojen rakentajat voivat määrittää käyttäjälle näkymättömästi komponenttien toimintatavat, kunhan ne noudattavat JSF-standardin rajauksia.

Olin viimeksi kokeillut JSF:aa 1.0-versiossa, jossa se oli varsin kankea eikä vastannut tarkoitustaan, mutta nykyinen 2.0-versio vakuutti. Sillä voi rakentaa B2B sovelluksia valmiista komponenteista merkittävästi vaivattomammin kuin käsin HTML:aa ja JS:aa jyystämällä. Hintana on tosiaan se, että täysin uusia komponentteja on vaikeampi rakentaa, mutta 99%:ssa projekteista valmiissa komponenteissa pitäytyminen on vain positiivinen juttu projektin liiketoimintatavoitteissa onnistumisen kannalta. Jälleen uuden sliderikomponentin keksiminen ei oikeasti hyödytä ketään, mutta saman ajan käyttäminen tuotteen iteroimiseen asiakkaiden kanssa taas hyödyttää.