Új hozzászólás Aktív témák

• jetarko csendes tag

  #6862

  #6846 Szmeby

  2015-02-18 20:56:24

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  jetarko

  csendes tag

  #6846 Szmeby

  #6846 Szmeby

  "A másik mód az lenne, hogy db-ben tárolok minden token és értéket..."
  Ismerek olyan rendszert, ahol adatbázisban tárolják az üziket. Megvan az előnye és a hátránya, ahogy a property fájlnak is. Megjegyzem, ott nem a Properties osztályt használják erre, hanem van rá egy egyedi megoldás.

  Én a magam részéről a property fájlt favorizálom, mert nem látom azt az üzleti esetet, hogy ezeknek az üzeneteknek futásidőben változniuk kéne. Van egy programod, támogat 30 különböző nyelvet. Az jó esetben 30 property fájl, csókolom.
  Ha adatbázisban lenne, akkor tuti készítenél hozzá valamit, amivel menet közben szerkeszteni is lehet. Az 30 db textarea. Ilyenkor történik az, hogy "ó, csak a magyar/angol nyelvűt írom át, a többi nem érdekes". És elszabadul a pokol.
  Vagy pl. hogyan tervezed kiírni a "Nincs adatbázis kapcsolat" hibaüzit, ha azt adatbázisban tárolod?
  Jó, persze a kivételeket bele lehet tolni a kódba, vagy property-be...

  Természetesen lehet olyan szöveg, ami gyakran változik, annak valóban nem property fájlban a helye, de a labelek, hibaüzik, stb. szerintem nem ilyenek.

  Na megcsináltam.
  Fejlesztés közben a tokeneket tárolom 1db properties fájlban, lehet 10 nyelv, akkor is csak egyben tárolom.
  Írtam egy fv-t, ami a property fájl alapján a tokeneket felveszi db-be, ha van értéke a fájlban, akkor az értéket beszúrja, ha nincs akkor az értékhez a token kerül be maga.
  A másik fv az adott nyelvhez tartozó property fájlt módosítja a db tartalma alapján. Ha ezt meghívom, akkor vagy 1db token értékét cseréli az adott nyelv property fájlban, vagy a db-ben tárolt összes értéket kiírja a fájlba.
  A db-be kerüljenek tokeneket csak akkor kell lefuttatni ha új token kerül a property-be, ekkor az új token bekerül db-be. Innentől csak a 2. fv dolgozik.
  Erre írtam egy felületet, ami onblur műveletre ajaxosan frissíti az adott property fájlban és db-ben szereplő értéket is.
  A cacheSeconds 1-re van állítva. Jelenleg 100 tokennel nagyon gyorsan változtatva a frontenden az értékeket remekül működik, a context újratöltéstől semmi memória nem növekszik.
  Ugye ez által futás közben bármikor beletudok nyúlni a token értékekbe, de a rendszer mégis a property fájlok alapján dolgozik, amihez gondolom valami gyors fa van építve, nem kell szarakodnom folyamatos db basztatás, cachelés dolgokkal.
  Azt még nem találtam ki, hogy ezzel a megoldással futás közben új nyelvet, hogy tudok hozzácsapni, de majd még agyalok rajta.
  A hibája ennek amit jelenleg látok, hogy a property fájl frissítéskor a fájl egésze újraírodik, ez ha nagyon sok token van lehet sokáig tartana. Ezt letesztelem hamarosan mennyi idő lehet 1milla tokent fájlba írni. A másik pedig az lehet, ha sok ember nagyon gyorsan sok tokent módosít egyszerre, de hát ezt nem tudom egymagam leszimulálni
  A db réteg fölöslegesnek tűnik és majdnem, hogy az is, de ha cserélem a war-t a tomcatemben és közben egyik token értékét átírtam, akkor a régi propertiekkel felül csapom a jelenlegit és elveszett a módosítás, ha nem szedem le előtte a property fájlt.
  Vélemény?

Új hozzászólás Aktív témák