Decemberi beszámoló – Limit

Zolnai Tamás, 2013. január 5.

     Ez a hónap is hozott magával néhány megoldandó problémát a lokalizációval kapcsolatban, melyek a po fájlokra való átállás következtében jöttek létre. Az sdf fájlos megoldás magában hordozott egyfajta robusztusságot, melyet – annak megszűnésével – közvetlenül a lokalizációt végző programokba kellett, illetve kell átültetni.
   Egyik legszembetűnőbb példa erre a felhasználói felületen megjelenő szöveges listák – mint például a menükkel – kapcsolatos probléma. Ha ezeket módosították a fejlesztés során, akkor legtöbb esetben rosszul jelentek meg a lokalizált felhasználói felületen.   Valahol rövidebb listák jelentek meg, de előfordult az is, hogy az egyes feliratok összekeveredtek és így teljesen érthetetlené vált az egyes menüpontok funkciója. Ezek a hibák a következő po fájl frissítéssel megszűntek így valójában ez a fejlesztők számára okozott leginkább gondot.
   Az sdf fájlok megszűnésével a lokalizáció által felhasznált adatok redundanciája csökkent, és éppen ezért az erre épülő megoldások helyett más megoldásra volt szükség. A probléma a transex3 program működésében volt. Ugyan találtam benne egy megoldási kísérletet, mely talán valamikor működött is, de az én szempontomból ez inkább volt félrevezető, mintsem célravezető. Végül egy kicsit jobban belemélyedve a kódba sikerült megtalálnom egy jónak tűnő megoldást, ugyan ezzel egyidejűleg egy lappangó hibára is fény derült. Egy programrészlet kétszer futott le a szükséges egy helyett, mely a legújabb változtatások hatására a végeredményben is változást eredményezett. Ezt kiküszöbölve még a hatékonyságon is sikerült javítani.
  A hónap másik felében az Alapítvány megbízásából belekezdtem a LibreOffice adatbázis-kezelőjének fejlesztésébe. Kaptam néhány konkrét fejlesztési ötletet, melyek legfőképp az érettségizők számára teszik egyszerűbbé a LibreOffice használatát az érettségi feladatok megoldásában. Az alapvető cél az, hogy ezek a feladatok megoldhatóak legyenek közvetlenül az adatbázis-kezelőn keresztül, illetve lekérdezések esetén teljes mértékben a tervezőnézetre lehessen hagyatkozni.
  Az adatbázis-kezelő felépítésének megismerését, illetve általában az új szolgáltatás bevezetésével járó feladatok megtapasztalását egy egyszerű funkció bevezetésével tartom célszerűnek, ami a következőképp néz ki. Gyakori feladat a lekérdezés eredményeként visszatérő sorok számának felső korlátjának megadása, melyet az SQL-ben a „LIMIT” illetve a „TOP” parancs tesz lehetővé. A LibreOffice adatbázis-kezelője ezt a funkciót csak SQL-nézetben nyújtja. Azt szeretnénk elérni, hogy a tervezőnézetben is elérhető legyen ez a funkció, melyet egy az eszköztáron található kombinált lista segítségével lehet elérni.
  A megvalósításnak több szintje van. A legfelső szint a felhasználói felület. A „Tervező” eszköztárat szeretnénk kibővíteni az említett kombinált listával. Ehhez módosítanunk kell az eszköztár leírását tartalmazó XML fájlt, létre kell hoznunk egy osztályt, mely kezeli ezt a felületi elemet, és végül össze kell kapcsolnunk ezt a kettőt. Így megjelenik a felhasználói felületen a korlát megadására alkalmas mező, de hatása még nincs a bevitt értékeknek.
   A következő szint a lekérdezéshez tartozó összes eszköztár állapotát figyelő és tároló osztály szintje. Ez az osztály (vezérlő) figyeli, hogy mely eszköztári elemek aktívak, illetve érhetők el, továbbá elvégzi az azokhoz tartozó adminisztratív teendőket. Ezen az osztályon keresztül lehet elmenteni a tervezőnézet egyes állapotait, továbbá SQL-nézetből való visszaváltás esetén ezen keresztül lehet inicializálni az eszköztárakat az SQL-parancsnak megfelelően. Tehát ezen osztály bővítésével a megadott érték ténylegesen tárolásra kerül és elérhetővé válik további feldolgozásra.
  A következő teendő a váltások során történő konverziók végrehajtása. Egyrészről a tervezőnézetben létrehozott lekérdezés alapján létre kell hozni az annak megfelelő SQL-parancsot az SQL-nézetbe való váltás során. Ehhez is megvan a megfelelő metódus mely a vezérlő osztálytól lekérdezve annak állapotjellemzőit felépíti az adott SELECT kifejezést. Így a korlátot tartalmazó mezőnek az értékét is lekérdezhetjük és beilleszthetjük az SQL-parancsba a „LIMIT” vagy a „TOP” kulcsszó társaságában.
   A másik irányú váltás is hasonlóan történik, csak itt az SQL-kifejezés alapján kell beállítanunk az eszköztár elemeit. Ehhez azonban kell egy saját SQL-elemző, mely értelmezi az adott kifejezést. Ez az elemző létrehoz egy egyszerűbb struktúrát, melyen keresztül könnyen lekérdezhetjük a kifejezés egyes jellemzőit, melyek alapján beállíthatjuk a vezérlő osztály állapotait. A korlátot megadó mező értékének beállításához tehát meg kell vizsgálnunk, hogy a kifejezésben szerepel-e a megfelelő kulcsszó és hogy milyen szám követi.
   Szinte már meg is van a megoldás, azonban maga ez az elemző a „TOP” kulcsszót például nem ismeri fel ezért is ad szintaktikus hibát, ha le szeretnénk futtatni. De a mi szemszögünkből talán nem is szükséges, hogy a „TOP” kulcsszót is le tudja kezelni, számunkra elég a „LIMIT” parancs is. Azonban ezen a téren is vannak hiányosságok, melyek az elemzés felsőbb szintjén helyezkedhetnek el. Egy teljesen egyszerű lekérdezés esetén, melyben csak egy tábla adott oszlopát kérdezzük le, a „LIMIT” kulcsszó hozzáfűzése „Az adattartalmat nem sikerült betölteni!” típusú hibához vezet. Rendezés esetén azonban rendben lefut. Tehát a feladatunk az elemző átírása, olyanra, hogy az felismerjen minden helyes „LIMIT” kulcsszót tartalmazó SQL-kifejezést. A „TOP” esetét hasonlóan meg lehet oldani.
   A megoldás utolsó momentuma a dokumentáció megírása. Egyrészről a felhasználók számára elérhető súgó megírása, másrészről a fejlesztők számára az új kódok és a régi de kevésbé dokumentált kódok tömör kommentelése.
   Tehát ez a terv vázlata, mely a forráskód böngészése során alakult ki és aminek megvalósíthatósága a következő hetekben derül majd ki.

Címkék: , , ,

Itt lehet hozzászólni !