Eräässä projektissa pääasiallinen asiakkaalle näkyvä käyttöliittymä on tehty Liferayn päälle. Käyttöliittymän lisäksi pidämme käyttäjät ja näiden oikeudet liferayn hallinnassa. Asiakkaille on olemassa omat Liferay instanssinsa eri teemoituksineen. Testiympäristöissä on tuotannon tilaa vastaavia referenssiinstansseja. Uudet sivut ja näiden oikeudet siirretään LAR tiedostoissa tuotantoon. Olemme myös käyttäneet Liferaytä piilottamaan tai näyttämään jotain ominaisuuksia vain tietyille käyttäjille.
Ongelmana on että emme ole testanneet ikinä automaattisesti LAR-tiedostoja. Tästä on seurannut useita huolimattomuusvirheitä. Haluamme että esimerkiksi vain tietyt käyttäjät näkevät jonkun portletin, mutta se onkin näkynyt kaikille
Olemme nykyään varautuneet deploymentteihin sekä testaamalla itse LAR-tiedostot, että ajamalla muutamia SQL-skriptejä tuotannon tietokantaa vasten. LAR-tiedostot ovat pakattuja XML-tiedostoja, joissa on mm. sivujen urlit ja hierarkiat pääsyoikeuksineen. Kun nämä ladataan tuotantoinstanssiin, tiedot kopioituvat lähes suoraan Liferayn tietokantaan. Tietokantatauluissa on myös XML:ää
LAR tiedostot ovat varmasti ihan kohtalainen tapa siirtää konfiguraatioita eri instanssien välillä. Ongelmana tapauksessamme on kuitenkin se että siirrämme niiden mukana hyvin tärkeitä ensimmäisen vaiheen autorisointitietoja. On hyvin kiusallista jos nämä menevät väärin. Testiympäristöissä käy myös silloin tällöin niin, että LAR-tiedosto hajoittaa Liferayn tietokannan tai jotkut käyttäjäoikeudet eivät siirry oikein.
Liferay on huono valinta projektimme käyttöliittymäksi. Emme käytä juurikaan siinä mukava tulevia ominaisuuksia. Olemme myös kustomoineet sitä, joten sen päivittäminen uuteen versioon on työlästä. Liferay saattaa olla hyvä valinta jos siinä tulevat ominaisuudet miellyttävät. Siitä huolimatta se on aikamoinen monoliitti ja kevyempiäkin ja modulaarisempia ratkaisuja on olemassa.
Ongelmana on että emme ole testanneet ikinä automaattisesti LAR-tiedostoja. Tästä on seurannut useita huolimattomuusvirheitä. Haluamme että esimerkiksi vain tietyt käyttäjät näkevät jonkun portletin, mutta se onkin näkynyt kaikille
Olemme nykyään varautuneet deploymentteihin sekä testaamalla itse LAR-tiedostot, että ajamalla muutamia SQL-skriptejä tuotannon tietokantaa vasten. LAR-tiedostot ovat pakattuja XML-tiedostoja, joissa on mm. sivujen urlit ja hierarkiat pääsyoikeuksineen. Kun nämä ladataan tuotantoinstanssiin, tiedot kopioituvat lähes suoraan Liferayn tietokantaan. Tietokantatauluissa on myös XML:ää
LAR tiedostot ovat varmasti ihan kohtalainen tapa siirtää konfiguraatioita eri instanssien välillä. Ongelmana tapauksessamme on kuitenkin se että siirrämme niiden mukana hyvin tärkeitä ensimmäisen vaiheen autorisointitietoja. On hyvin kiusallista jos nämä menevät väärin. Testiympäristöissä käy myös silloin tällöin niin, että LAR-tiedosto hajoittaa Liferayn tietokannan tai jotkut käyttäjäoikeudet eivät siirry oikein.
Liferay on huono valinta projektimme käyttöliittymäksi. Emme käytä juurikaan siinä mukava tulevia ominaisuuksia. Olemme myös kustomoineet sitä, joten sen päivittäminen uuteen versioon on työlästä. Liferay saattaa olla hyvä valinta jos siinä tulevat ominaisuudet miellyttävät. Siitä huolimatta se on aikamoinen monoliitti ja kevyempiäkin ja modulaarisempia ratkaisuja on olemassa.
Comments
Post a Comment