JavaOne 2013 – Tiistai

Tiistai oli vähemmän innostava päivä kuin maanantai. Osa syytä menee itselle – olin buukannut kaikenlaista teknistä yksityiskohtaa. Luennoijat eivät myös olleet erityisen inspiroivia, vaan lukivat suoraan kalvoja ja aivan liian pieniä koodiesimerkkejä monotonisella äänellä – joskus on hyvä nähdä huonoja esimerkkejä miettiäkseen itse miten parantaa 😉

Jotain jäi jokatapauksessa haaviin. JSF 2.2 on pistetty aikalailla uusiksi. Siellä on kiinnostavia piirteitä mm. JSF Flow, joka on muotoiltu esim. Spring Web Flow/Oracle ADF flow mukaan. Se on periaatteessa laajennus navigaatioon, jossa sensijaan että käyttäjä voi pomppia sovelluksessa mihin haluaa, otetaan tarkemmin haltuun reitit ja vaihtoehdot. JSF Flowssa on selkeä alku ja lopputila, ja vakioelementit välissä. Yksi elementeistä on näyttää näkymä, mutta yhtälailla voi olla ehdollista navigointia, logiikan arvoja. Flow voi sisältää myös subflow-elementtejä. Periaatteessa flow on kuin Javan funktio – sillä voi olla parametreja ja paluuarvoja. Tämä on ollut itsellä suht selkeä puoli jo jonkin aikaa, mutta käytännön kokemus on vielä ohutta.

Lisäksi JSF:stä löytyy nyt ’contract’ malli jossa voidaan resurssikansioon paketoida kuvien ja scriptien ohella nyt myös template ratkaisuja joissa on ajettavaa koodia. Demossa näytettiin miten contract-valikoimasta voi valita vaihtoehtoja helposti esim. url parametrilla. Tämä mahdollistaisi esim. käyttöliittymän vaihdettavuuden skinnin-tekniikan tapaan, tai mobiili ja työasemakäyttöliittymät rinnakkaisissa template-kansioissa.

Last but not least: HTML5 pohjainen template malli on aika miellyttävä, joskin siihenkin näyttäisi omia sudenkuoppiaan liittyvän. Tämä haasta Wicketin mukavasti – ja toisin kuin Wicketissä JSF:ssähän ei ole tarpeen toistaa käyttöliittymäelementtien rakennetta koodin puolelle vaan riittää että templatessa on ne merkattu – niihin pääsee käsiksi automaattisesti koodista.

2013-09-24 09.02.00

Project Avatar oli uteliaan tutustumisen arvoinen. Äärimmäisen puuduttavasta esityksestä huolimatta kyseessä on juuri open sourceksi avattu hanke jossa on kaikenlaista apua HTML5+JavaScript asiakasohjelmien tekoon. Yksi elementti on Avatar.js kirjasto, joka on periaatteessa Node.js muunnettuna JVM-kelpoiseen muotoon. Java virtuaalikoneen päällä ajettuna saadaan nauttia monista virtuaalikoneen piirteistä joista vähäisin ei ole koodin optimointi ajon aikana dynaamisesti. Kirjastosta löytyy muutakin, ilmeisesti single page app voisi saada tukea tältä suunnalta jos JSF ei kiinnosta. Tämä ei kuitenkaan ole vielä osa Java EE arkkitehtuuria, vaan valinnainen lisäprojekti, aika tuore myöskin. Mutta kiinnostava. Penteleellisen vaikea löytää Googlella kun kaikki linkit vievät sinisiin metsäolentoihin.  Tässä linkki oikeaan proggikseen: https://avatar.java.net/

stack

Nashorn on tietysti uusin ja kaunein kiillotettu JavaScript ajomoottori joka korvaa aiemman Rhinon.

JPA 2.1 on päällisin puolin aika pieni päivitys, mutta kun siitä tunti puhuttiin päästiin syvemmälle porautumaan. Itselleni mielenkiintoinen lisä olivat Object Graph piirteet, käytännössä idea on vanha (projektio, kenttäryhmä) mutta JPA tuki on uusi juttu.  JPA 2.0 versioon asti JPA hakee kolmessa moodissa tavaraa: lazy, eager, tai fetch join – ja haettaessa kannasta tauluja haetaan aina kaikki. Nyt JPA 2.1 Object Graph antaa mahdollisuuden määrittää itse mitä tauluista milloinkin halutaan. Näin muuttuu helpommaksi räätälöidä hakuja jotka välillä hakevat vain muutaman kentän. Huom! id ja versiokentät haetaan aina, niitä ei saa edes pois päältä. Kaikki muu on valinnaista.

Mielenkiintoista oli myös JPA 2.1 tuki Stored Procedure-hauille. Itse pidän näppini visusti erossa moisista epästandardeista hirvityksistä – mutta monessa legacy järjestelmässä niitä löytyy, ja ne pitäisi saada kytketyksi uuteen hienoon kiiltävään Java-systeemiin. Nyt se onnistuu, suoraan JPA:n kautta. Parametreja liikkuu tarvittaessa sisään ja ulos, tai koko ResultSetin voi palautella arvona. Kiintoisaa. Mutta ei kyllä kovin esteettistä eikä selkeää.

Entity Graph

Jahas, ei kun kohden keskiviikkoa. Luvassa pitäisi olla kiinnostavampia luentoja. Tänäänkin olisi ollut mutta nuo peruskaura-apit nyt vain on hyvä tuntea läpikotaisin, ja täällä pääsee vähän myös kuulemaan perusteluita sille miksi ne ovat mitä ovat (JSF työryhmässä oli alunperin Swing guru, siksi tilallisuus on siellä niin kova juttu 😉

No niin, illalla olisi ollut RedHatin sponsoroimat JBOSS bileet luvassa – mutta tein brutaalin päätöksen ja menin sensijaan koodaamaan. Luvassa oli nimittäin Java EE 7 hands on lab. Joskin suuri osa on jo tuttua, on siellä uusiakin osia itselleni, esim. JSF Flow käytännössä, ja eräajorajapintojen EE standardit. Jos jotain olen oppinut koulutellessa, niin koodaamaan nopeasti ja pistämään vajanaiset ohjeet ja ympäristöt kuntoon tarvittaessa paineen alla ja nopeasti :p Labrojen puutteellisista ohjeista huolimatta paukutin ratkaisut paikalleen siihen tahtiin että kun muut vielä tekivät ensi harjoitusta, itsellä oli jo neljä kasassa. Hoksasin jossain vaiheessa että nopeimmalle ratkojalle oli tarjolla krääsää, joten Arun Gupta tuli kiikuttamaan hienon mustan Java-pipon palkaksi nopeimmasta tehdävän ratkaisusta. Harmi ettei niitä voinut napata useampia kerralla :p Varsin mielenkiintoisia harjoitteita, ja aika lupaava alusta tuo EE 7. Eräajoautomatiikka on itselle vielä vierasta kenttää mutta ihmeen nopeasti CVS tiedostot paukkuivat EE serverillä. Ja pipollekin on käyttöä iltaisin ja aamuisin, kun aurinkoa ei näy kylmä valtaa ihan yhtä nopeasti kuin kotikamarallakin 😉

Mainokset

JSF 2.2 Faces Flow ja HTML5 friendly layout

Odotellessa tulevaa Java EE 7 sekä Java SE 8 standardia olen seuraillut yksittäisten spesifikaatioiden kehitystä. Yksi mielenkiintoinen päivitys on Java EE 7:n tuleva JavaServer Faces 2.2 versio. Se on näennäisesti taas minor update, eli ei arkkitehtuurin uusintaa kuten aikanaan 2.0 päivitys – mutta pienet päivitykset kasaantuvat aika mielenkiintoisesti.

Mitäpä on odotettavissa JSF 2.2 versiossa? Yksi kiintoisa piirre on Wicket-frameworkin tapainen mahdollisuus käyttää HTML5 pohjaa ja id attribuutteja aiemman tag-mallin sijasta. Tässä esimerkki uudesta JSF 2.2 leiskasta tähän tapaan tehtynä:

< !DOCTYPE html>
< html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:jsf="http://java.sun.com/jsf" xmlns:f="http://java.sun.com/jsf/core">
    < head jsf:id="head">
        < title>Putting it all together < /title>
        < script jsf:target="body" jsf:name="js.js"/>
        < link jsf:name="css.css" rel="stylesheet" type="text/css" />
    < /head>
    < body jsf:id="body">
        < form jsf:id="form" jsf:prependId="false">
            < label jsf:for="name">Name < /label>
            < input jsf:id="name" type="text" jsf:value="#{complex.name}">
                < f:ajax execute="@this" render="progress"/>
            < /input>
            < label jsf:for="tel">Tel < /label>
            < input jsf:id="tel" type="tel" jsf:value="#{complex.tel}">
                < f:ajax execute="@this" render="progress"/>
            < /input>

            < label jsf:for="email">Email < /label>
            < input jsf:id="email" type="email" jsf:value="#{complex.email}">
                < f:ajax execute="@this" render="progress"/>
            < /input>

            < label for="progress">Progress < /label>
            < progress jsf:id="progress" max="3">#{complex.progress} of 3 < /progress>

        < /form>
    < /body>
< /html>

Kiintoisaa? Miksei, onhan se. Toinen itseä kiinnostava tutkaan osunut piirre on JSF Faces Flow. Idea on itselle tuttu Spring Web Flow moduulin puolelta – sensijaan että navigointisäännöt naputellaan sivuihin, määritellään sivuilla liikkuminen ja eri vaihtoehdot erilliseen tiedostoon. Tässä ei ole kuitenkaan kyseessä vain navigointi, vaan page flow voi myös sisältää logiikkaa, virhekäsittelyä, jne. Faces Flow on valittu ns ’Big Ticket Feature’:ksi, eli on merkittävä osa JSF alustaa ja sen ympärille rakentuu paljonkin pientä.

Yksi osa on uusi Scope annotaatio, @FlowScoped, joka määrittää luokan elinkaareksi senhetkisen Flown (kääntäisikö tuon virtaukseksi? Aika kömpelö käännös). Tarkoittaa että scope voi olla yli yhden requestin mutta vähemmän kuin session verran. Tätä voisi vertailla hieman @FlashScoped-laajuuteen, mutta viimekädessä elinkaaren määrittää siis määritelty flow, ei se montako kutsua serverille tehdään.

@FlowScoped ottaa flow id parametrin joka määrittää mihin flow-virtaukseen se kuuluu.

Esimerkki @FlowScoped beanistä:

@Named
@FlowScoped(id = "someFlowName")
public class SomBean {
    public String someReturn() {
        return "/somePage.xhtml";
    }
}

Käytössä on oletuksia mitkä helpottavat elämää: flow oletussivu voidaan luoda luomalla kansio jonka nimi on sama kuin flow id, sekä .xhtml tiedosto jonka nimi on edelleen sama kuin flow id, esim:

/someFlowName/someFlowName.xhtml:

<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:j="http://java.sun.com/jsf/flow"
>
    <f:metadata>
        <j:faces-flow-definition>
            <j:faces-flow-return id="someReturnName">
                <j:navigation-case>
                    <j:from-outcome>#{someBean.someReturn}</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>
        </j:faces-flow-definition>
    </f:metadata>

    <!-- Rest of view -->
</html>

Flow-tiedostojen välillä voi navigoida flow-id:n avulla, eli navigaatiojärjestelmä tunnistaa nyt flow id:n. Flow id voi olla sama kuin tiedostonimi, tai se voidaan määrittää j:faces-flow-definition elementin id-attribuutilla jos tiedostonimeä ei haluta käyttää. Navigointi flow-sivulta toiselle tapahtuu tähän tapaan:

 <h:commandLink value="Enter flow" action="someFlowName" />

No niin, tässähän ei ole mitään uutta. Aiemminkin JSF:ssä on voitu navigoida sivulta toiselle sivunimen perusteella. Uutta onkin se, että flow node (virtaussolmu? :p) voi olla muutakin kuin näkymä, view. Se voi olla myös Switch (EL lause joka evaluoi mikä on seuraava node), Return (virtauksen paluuarvo),  Method Call (vapaavalintaisen metodin suoritus ja navigaatio), tai Faces Flow Call (uuden flow-sarjan käynnistys).

Ja tässä vähän mehukkaampi Faces Flow määritys:

 

<f:metadata>
        <j:faces-flow-definition>

            <j:initializer>#{someBean.init}</j:initializer>
            <j:start-node>startNode</j:start-node>

            <j:switch id="startNode">
                <j:navigation-case>
                    <j:if>#{someBean.someCondition}</j:if>
                    <j:from-outcome>fooView</j:from-outcome>
                </j:navigation-case>
            </j:switch>

            <j:view id="barFlow">
                <j:vdl-document>barFlow.xhtml</j:vdl-document>
            </j:view>
            <j:view id="fooView">
                <j:vdl-document>create-customer.xhtml</j:vdl-document>
            </j:view>

            <j:faces-flow-return id="exit">
                <j:navigation-case>
                    <j:from-outcome>/exit</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>
            <j:faces-flow-return id="error">
                <j:navigation-case>
                    <j:from-outcome>/error</j:from-outcome>
                </j:navigation-case>
            </j:faces-flow-return>

            <j:finalizer>#{someBean.finish}</j:finalizer>

        </j:faces-flow-definition>
    </f:metadata>

 

Joten tällaista tänä vuonna. Vuosi 2013 on Javan kannalta jännä vuosi tulevien standardien johdosta. Spring Framework 4 tulee luonnollisesti sisältämään tuen myös EE 7 ja SE 8 piirteille, se on jo työn alla.

 

JSF 2.2 ja kunnon HTML-yhteensopivat templatet

No niin, JavaServer Faces on elänyt aika elinkaaren. Ensimmäisessä versiossaan siinä käytettiin JSP tekniikkaa sivupohjana, ja se mahdollisti hirvitykset kuten:

<h2>Categories</h2>
<ul>
 <% 
 ArrayList<Category> categories = Category.selectAll();
 for (int i = 0; i < categories.size(); i++) {
 %>
 <li>
 <h:form>
 <h:inputHidden binding="#{BookCategories.bookBean.categoryId}" value="<%= categories.get(i).getId() %>" />
 <h:commandLink action="#{BookCategories.filterByCategory}">
 <h:outputText value="<%= categories.get(i).getName() %>" />
 </h:commandLink>
 </h:form>
 </li>
 <% } %>
</ul>

Joka ei lisäksi tietysti edes toimi! Mutta vaikka toimisikin, antaa myös sydänkohtauksen mille hyvänsä HTML editorille (ja Web Developer rassukalle joka yrittää saada sivua näyttämään hyvältä selaimessa)

JSF 2 paransi hieman asiaa ottamalla faceletit käyttöön, mutta edelleen sivuleiska on täynnään kaikenlaista ei-html standardimaista puppua:

    	<h1>JSF 2 dataTable sorting example</h1>
    		<h:dataTable value="#{order.orderList}" var="o"
    			styleClass="order-table"
    			headerClass="order-table-header"
    			rowClasses="order-table-odd-row,order-table-even-row"
    		>

    		<h:column>
    			<f:facet name="header">
    			   <h:commandLink action="#{order.sortByOrderNo}">
    				Order No
    			   </h:commandLink>
    			</f:facet>
    			#{o.orderNo}
    		</h:column>

    		<h:column>
    			<f:facet name="header">
    				Product Name
			</f:facet>
    			#{o.productName}
    		</h:column>

    		<h:column>
    			<f:facet name="header">Price</f:facet>
    			#{o.price}
    		</h:column>

    		<h:column>
    			<f:facet name="header">Quantity</f:facet>
    			#{o.qty}
    		</h:column>

    	    </h:dataTable>

Samaan aikaan muut frameworkit kuten Wicket tekevät puhtaita HTML sivuleiskoja. Nyt JSF 2.2:sen myötä näyttäisi sama piirre olevan tulossa myös Java EE alustan web-standardikehikkoon JSF:ään, tässä maistiainen tulevasta:

 

< !DOCTYPE html>
< html xmlns="http://www.w3.org/1999/xhtml"
 xmlns:jsf="http://java.sun.com/jsf" xmlns:f="http://java.sun.com/jsf/core">
 < head jsf:id="head">
 < title>Putting it all together < /title>
 < script jsf:target="body" jsf:name="js.js"/>
 < link jsf:name="css.css" rel="stylesheet" type="text/css" />
 < /head>
 < body jsf:id="body">
 < form jsf:id="form" jsf:prependId="false">
 < label jsf:for="name">Name < /label>
 < input jsf:id="name" type="text" jsf:value="#{complex.name}">
 < f:ajax execute="@this" render="progress"/>
 < /input>
 < label jsf:for="tel">Tel < /label>
 < input jsf:id="tel" type="tel" jsf:value="#{complex.tel}">
 < f:ajax execute="@this" render="progress"/>
 < /input>
 
 < label jsf:for="email">Email < /label>
 < input jsf:id="email" type="email" jsf:value="#{complex.email}">
 < f:ajax execute="@this" render="progress"/>
 < /input>
 
 < label for="progress">Progress < /label>
 < progress jsf:id="progress" max="3">#{complex.progress} of 3 < /progress>
 
 < /form>
 < /body>
< /html>

 

 

 

Pieni yksityiskohta? Yep, mutta ne ratkaisevat. Itse pidän aina siitä kun asiat menevät yksinkertaisempaan suuntaan:

Java on ollut aina hyvä varuste raskaisiin isoihin yrityssovelluksiin (joskin tästä voidaan käydä uskonsotia, mutta uskottavia referenssejä on riittävästi Javan puolesta 😉 – mutta viime vuosina sillä on voinut näperrellä nopeammin, halvemmin, ketterämmin myös pienempiä start-up juttuja uskottavalla tavalla.

Jos ensimmäisen prototyypin saa käyntiin tunneissa tai minuuteissa viikkojen sijaan, saa aiemmin arvokasta palautetta, ja etenkin ketterissä hankkeissa tämä on elintärkeää.