JavaFX:n soveltuvuus MVVM-arkkitehtuuriin
JavaFX MVVM-arkkitehtuurissamme on syytä korostaa serveripään tilattomuutta sekä tukeutumista Java EE:n standardi- ja ”best practise” -ratkaisuihin. Tilattomuus takaa siedon hyvin korkealle kuormitukselle. Nykyisin HTML5-sovellukset ovat TSA-arkkitehtuurin mukaisia. Niissä tukena ovat Javascript-kirjastot, jotka vähentävät sovelluskoodia clientilla. Kattavimpia valmiita alustoja ratkaisuille ovat Oracle JET ja Angular 1 tai 2. Yhteyttä clientin ja
Desktop-sovelluksen hybridi arkkitehtuuri
Tietokantakeskeiset desktop-sovellukset (kuvassa ”Traditional desktop-app”) on perinteisesti tehty siten, että client-koneella oleva sovellus kutsuu tietokantapalvelimella olevaa sovelluksen tietokantaa. Tällaista sovellusta on raskasta päivittää, asennus on tehtävä kaikille client-koneille. Mikäli sovelluksesta halutaan tehdä web-versio, on lähes koko sovellus kirjoitettava uudelleen. Toisaalta desktop-sovellus on helpompi toteuttaa kuin vastaava websovellus, jos sovelluksessa on
JavaFX ja MVVM-arkkitehtuuri
Aloitamme Faberconilla uuden blogisarjan, jossa käsitellään MVVM-mallin käyttämistä JavaFX-sovelluksissa. Tarkoituksena on esitellä yleiskäyttöinen MVVM-arkkitehtuurimalli JavaFX:lle. JavaFX on Javan uusin käyttöliittymätekniikka graafisia desktop-sovelluksia varten. JavaFX on pikkuhiljaa syrjättänyt 1990-luvulta käytössä olleen Swing-tekniikan. JavaFX sovelluksia voidaan tehdä joko XML-käyttöliittyminä tai ohjelmallisesti Swingin tapaan käyttäen JavaFX:n käyttöliittymäkomponentteja. Seppiä kiinnostaa XML-käyttöliittymät, ne edustavat nykysuuntausta
Javascriptin koodausohjeita
Näitä ohjeita voi käyttää portlettien kanssa tai aivan yhtä hyvin soveltaen kaikkialla muualla, missä Javascriptia käytetään. Javascript on dynaaminen, heikosti tyypitetty skriptikieli, jonka ongelmat ilmenevät käännösvaiheen puuttuessa vasta ajovaiheessa (runtime errors). Heikko tyypitys on yksi syy näihin hankalasti löytyviin virheisiin. Javascriptin muuttujan tyyppi määräytyy sijoitettavan arvon perusteella ja vaihtelee, jos
Sivusiirtymien toteutus SPA-portletissa
Kuten jQueryn osalta oli laita, niin yksinkertaisin SPA-arkkitehtuurin ratkaisu Angularin kanssakin on kirjoittaa kaikkien vaihtoehtoisten moduleiden määritys sivulle peräkkäin ja hallita sitten Javascript-koodissa, mitä tai mitä osiot haluaa näyttää. Tämä on tehokas ja yksinkertainen keino, eikä mitään Angularin $routea tarvita. Mutta ongelmana on se, että jokainen käyttäjä voi lukea selaimesta