‘base’ címkével ellátott bejegyzések

Május – Base tábla import

Zolnai Tamás, 2013. június 5. szerda

    Májusban a LibreOffice adatbázis-kezelőjének egy új funkciójának a fejlesztésébe kezdtem. Ez a funkció a strukturált szöveges (*.csv kiterjesztés) állományokból és az LO táblázatkezelője által támogatott más formátumokból való közvetlen táblaimportálás. Egy közvetlen importálási lehetőség szintén az érettségizők dolgát könnyítené meg – ahogy a csúcsérték/limit megadására használt beviteli mező is – mely az elsődleges szempont, de ez a funkció általában is sok felhasználót érint. Mi sem mutatja ezt jobban, mint az Apache OpenOffice Bugzilla-ján található megfelelő bug jelentés, amely a szavazatok számát tekintve az első 19 között szerepel. (Limitált számú szavazat áll rendelkezésére minden Bugzilla felhasználónak, és ezekkel a szavazatokkal lehet szavazni azokra a bugokra/funkciókra, melyek kiemelten fontosak az adott felhasználó számára.)

Bug jelentés az Apache OpenOffice Bugzilla-ján:
https://issues.apache.org/ooo/show_bug.cgi?id=51904
Megfelelő LibreOffice bug jelentés:
https://bugs.freedesktop.org/show_bug.cgi?id=51872

   Valójában a táblaimportálás nem egy teljesen új funkció. Két különböző módja is van a probléma megoldásának. Egyrészről a táblázatkezelőt megnyitva és abba importálva bármilyen általa támogatott fájlt (ide tartozik a *.csv kiterjesztés is) és onnan kijelölve a táblázat felhasználni kívánt részét, másolás+beillesztéssel létrehozható egy új tábla az éppen megnyitott adatbázisban.

   Másik hasonló megoldási út az adatbázis-kezelő „Kapcsolódás létező adatbázishoz” opciójának használata az „Adatbázistündér” ablakban. Ezzel a opcióval rá lehet kapcsolódni tényleges adatbázisokra, de akár a táblázatkezelő által használt fájlokra és szöveges állományok egy csoportjára is, úgy értelmezve őket, mint egy adatbázis. A kapcsolódás után kapunk egy új adatbázisfájlt, mely táblaként tartalmazza az összes munkalapot az adott Calc fájlból, illetve az összes *.csv/*.txt fájl tartalmát az adott mappából. Ez a kapcsolat azonban „csak olvasható” hozzáférést biztosít a fájlokhoz, módosítási lehetőséget nem. Éppen ezért ebből az adatbázisból szintén másolás+beillesztéssel át kell másolni a táblákat abba az adatbázisba, amelybe ténylegesen importálni szeretnénk.

   Mindkettő megoldásnak megvannak az előnyei és a hátrányai a másikhoz képest, de ami közös bennük, hogy mindkettő esetben meg kell nyitni egy másik ablakot (1 → Calc, 2 → Base) és másolás+beillesztéssel átmásolni az adott táblát. Ehelyett az új, ténylegesen az importálást célzó funkció közvetlenül elérhető lesz abban az adatbázisablakban, amelyikbe importálni szeretnénk és a vágólap műveleteket sem szükséges alkalmazni.

   Mivel a „Kapcsolódás létező adatbázishoz” funkció már létezik, és minden támogatott adatbázis (ide tartoznak a táblakezelő által támogatott formátumok is) tábláihoz hozzáférést nyújt, ezért a tervezett import varázslóban is ugyanazon felületen lehet majd kapcsolódni egy adott adatbázishoz. A különbség annyi, hogy a kapcsolódás után ki lehet választani az importálni kívánt táblákat és a táblák beszúrása az aktuális adatbázisba a „Tábla másolása” nevű párbeszédablak felhasználásával történik majd.

   Ahogy említettem a hónapban a funkció megvalósításába csak belekezdtem. Valójában egy részletes terv elkészítéséig jutottam, mely megvalósítva úgy fog kinézni, ahogy fent leírtam. Három jól elkülöníthető része van ennek a tervnek, illetve magának a megvalósításnak.

   Az első rész az „Adatbázistündér” adatbázis-kapcsolódáshoz tartozó részének kiemelése a jelenlegi osztályából egy újba, ezzel lehetővé téve annak felhasználását a tervezett „Importtündér” megvalósításában. A két varázsló csak két oldalban fog különbözni. Egyrészről az első oldalon az „Importtündér” esetén csak egy lista lesz azon adatbázis típusának kiválasztásához, amelyből importálni szeretnénk, míg az „Adatbázistündérnél” ugyanezen a kezdőoldalon három funkció érhető el, köztük a „Kapcsolódás létező adatbázishoz” egy ugyanolyan listával. Másrészről az utolsó oldalon, ami az „Adatbázistündérnél” a „Mentés és végrehajtás” nevet kapta, ott az „Importtündérnél” az importálni kívánt táblák kiválasztására alkalmas felület lesz elérhető. Az itt leírtak a tervezett felülettel kapcsolatosak, tehát a megvalósítás nézet részét tartalmazzák (lásd modell-nézet-vezérlő).

   A megvalósítás második része a nézet mögött meghúzódó adatbázis-kapcsolat felhasználása az adott adatbázis (illetve munkafüzet) tábláinak a lekérdezésére. Ez a kapcsolat a már említett „Kapcsolódás létező adatbázishoz” opciónak köszönhetően adott és ennek felhasználására a létező API-nak köszönhetően elég jó eszközök állnak rendelkezésre. Így a lekérdezett táblaneveket egyszerűen lekérdezhetjük és megjeleníthetjük az „Importtündér” utolsó „Tábla kiválasztása” oldalán, majd hasonló módon felhasználhatjuk őket a tényleges importálásnál. (Ez a rész a modell)

   A harmadik lépés a kiválasztott táblák átalakítása olyan struktúrává, amilyen formába a vágólapra másolás során kerülnek. Ezt az alakot felhasználva be lehet járni ugyanazt az utat, amit a másolás+beillesztés esetén jár be a program, így elérve a „Tábla másolása” ablak felhasználását. Ennek az ablaknak és a hozzá kapcsolódó opcióknak nagy előnye, hogy az adott adatbázisban használatos adattípusoknak megfelelően lehet beállítani a mezők típusát, ami különböző típusú adatbázisok közötti tábla mozgatás esetén lehet lényeges. A munkafüzetek és szöveges állományok importjánál ez még inkább fontos tényező, hiszen szöveges állomány esetén még kevésbé egyértelmű az adattípus. A tábla átalakítása vágólapra helyezhető formátumba szintén könnyen elérhető adott osztályok felhasználásával, továbbá a vágólap tényleges felhasználásának mellőzésével is el lehet érni azt, hogy lefusson a beszúráskor lefutó kódrészlet. (Ez pedig a vezérlő)

   Tehát a terv így néz ki általában. A tényleges tervtől csak annyiban tér el, hogy nem tartalmazza a megvalósító osztályok és a mintául használt kódrészletek megjelölését. Ahogy említettem elég nagy része a funkciónak már adott, a legtöbb munka a felhasználói felület kialakításával lesz. A háttérben dolgozó mechanizmusokat a már létező osztályok egyszerű felhasználásával meg lehet valósítani. Ez a megvalósítás a következő hetekben várható.

   Végül elérkeztem az ösztöndíjas napjaim végéhez és egyben az utolsó beszámolom befejezéséhez, úgyhogy köszönöm a figyelmet, remélem elég érthető és érdekes írásokat sikerült közzétennem. Köszönöm az Alapítványnak a lehetőséget és a támogatást. Kelemen Gábornak is köszönet jár a beszámolók alapvető nyelvtani hibáinak korrigálásáért és a szakzsargon kifejezéseinek érthetőbbé tételéért. Ami engem illett, továbbra is folytatom LibreOffice-os fejlesztői tevékenységemet. A jelen beszámolómban leírt terv megvalósítása után a GSoC keretében fogok – ezúttal a Writer-hez – hozzáadni egy új funkciót (karakterszegély). A későbbi terveim még nem rajzolódtak ki előttem teljes valójukban, de bizonyára azok között is ott lesz a LibreOffice.

Február – Lekérdezés tulajdonságai

Zolnai Tamás, 2013. március 5. kedd

     A múlt hónapban írtam arról, hogy a limit megadására szolgáló eszköztári elem megvalósítása során milyen programozói eszközök és lehetőségek álltak rendelkezésemre, és hogy az adott megoldásnak milyen korlátai és lehetőségei vannak. Miután a módosításokat tartalmazó patch-et beküldetem elbírálásra, felmerültek további lehetőségek és igények a megvalósítással kapcsolatban.
   Néhány kisebb meggondolandó dolog mellett a leginkább kiemelhető igény a nem arab számjegyek használatára volt. Felmerült, hogy lehetővé lehetne-e tenni az olyan számjegyek használatát, melyek például a hindi, a kínai vagy a héber nyelvben találhatóak. A LibreOffice kódbázisában éppenséggel vannak erre szolgáló eszközök, és így sikerült is valamilyen szinten megvalósítani ezt a feladatot. Egy kicsit jobban utána nézve ennek a területnek azonban kiderült, hogy ha sikerül is teljes mértékben megteremteni az ilyen számjegyek használatának lehetőségét, akkor ez a beviteli mező lesz az egyetlen, amely ilyen tulajdonságokkal bír. Éppen ezért ezt az ötletet végül elvetettem. Ugyanakkor a megvalósításhoz kiválasztott osztályok megléte előrevetíti annak lehetőségét, hogy a jövőben ez a lehetőség globálisan elérhetővé váljon a LibreOffice-on belül.
   Egy másik jóval égetőbb igény a későbbi fejleszthetőség szempontjából jobb megvalósítás elérése volt. Felhívták figyelmemet egy olyan osztályra (NumericBox), mely olyan kombinált listát valósít meg, mely számokat vár a felhasználótól és ellenőrzi is, hogy vajon a begépelt szöveg az számként értelmezhető-e vagy sem. Ezen osztály használata egyrészről a későbbiekben elősegíti az olyan általános funkciók bevezetését, mint például a nem arab számok használata a beviteli mezőkben. Másrészről ez az osztály olyan funkciókat is tartalmaz, melyek növelik a felhasználói élményt. Ilyen funkció például a számok három számjegyenkénti elkülönítése a beállított szeparátorral (2,000,000) vagy a felhasználó által elgépelt szöveg automatikus javítása. (123h → 123).
    Tehát néhány változtatás után végül bekerült az új funkció a központi kódbázisba. Általános elvárás azonban minden eszköztári elemmel kapcsolatban, hogy azok elérhetőek legyenek a menürendszerből is. A tervező nézethez tartozó eszköztár összes többi eleme hasonló módon a „Szerkesztés” vagy a „Nézet” menüpontok alatt érhetőek el. Azonban ezek az elemek csak kapcsolóként működnek és így azok két állapotát (aktív/inaktív) a menüsorban közvetlenül jelezni lehet, pipával vagy grafikus effekttel rendszertől függően. Az általam megvalósított elem azonban egy beviteli mező, éppen ezért azt egy ablakban kellett elhelyezni. Mivel azonban a tervező nézetben nincs olyan ablak, mely tartalmilag megfelelne erre a célra, ezért egy új párbeszédablakot készítettem. Ez az ablak a Szerkesztés menüben érhető el, a “Query Properties” (magyar megfelelője valahogy így hangzik majd: „Lekérdezés tulajdonságai”) menüpontot választva jelenik meg. Az itt elért ablak a limit érték beállítása mellett lehetővé teszi a „Különböző értékek” kapcsoló állapotának változtatását is.
  A párbeszédablak megvalósításának három szintje van, melyeket már az eszköztári beviteli mező esetén is említettem. Ebből kettőnek a használat változatlan módon jelenik meg. Ez a kettő a központi vezérlő, mely a belső állapotokat tárolja, illetve az olyan felhasználói események kezelése, mint begépelés, lista megnyitása, szöveg kijelölés stb. A harmadik szintet a felhasználói felületet leíró XML fájlt jelenti. Ezen a téren már megfigyelhető néhány különbség. Az eszköztárak és a menüsorok leírására olyan XML fájlokat használ a rendszer, melyben valójában csak az adott elem azonosítója és az elemek sorrendje van definiálva. Ilyen esetekben ez elég is, hiszen elég kötött az egyes elemek elrendezése. Egy párbeszédablak, illetve bármely más ablak esetén azonban a leíró fájlban definiálni kell az elemek elhelyezkedését, méretét, méretezhetőségét, stb.
     A LibreOffice-ban nemrég került bevezetésére az XML fájlok használata (.ui kiterjesztés) az ablakok leírására. Azelőtt más típusú fájlok (.src\.hrc) segítségével lehetett definiálni a megjelenést. Ugyan én nem nagyon mélyedtem bele a régi típusú tervezés lehetőségeibe, de annyit tudok, hogy azelőtt koordináták alapján, manuálisan lehetett megadni az egyes elemek elhelyezkedését és a méret is statikusan volt megadva. Az új koncepcióban a koordináták teljesen eltűntek és leginkább a weboldalak írásához hasonló módon lehet tervezni, melyben dinamikus méretezési lehetőségek is helyet kapnak. Egyik legnagyobb előnye, hogy a Glade nevű programmal lehetővé válik, hogy a fájlok manuális módosítása helyett grafikus felületen lehessen megtervezni a kinézetet, azonnal látva a változtatások eredményét.
   Elég egyszerű ablakról lévén szó, sikerült megoldanom nagyobb stílustervezői tapasztalat nélkül, köszönhetően azon útmutatóknak, melyek találhatóak ebben a témában. Ezután már csak egyetlen dolog maradt hátra: a párbeszédablakhoz elkészíteni a súgót, melyet többek között szükségessé tesz az ablakhoz tartozó súgó gomb megléte is. Egyúttal a limit tervező nézetben való használatának útmutatóját is elkészítettem és ezzel vált teljessé az új funkció megvalósítása. Éppen ezért a következő hónapban áttérek tevékenységi köröm másik területére, a lokalizációra, mely ugyan láthatóan jól bírta az átállást, de hatékonyság területén még van mit javítani rajta.

A „Lekérdezés tulajdonságai” ablak megvalósításának kódja itt elérhető: https://gerrit.libreoffice.org/#/c/2508/

Januári beszámoló – Limit megvalósítás

Zolnai Tamás, 2013. február 5. kedd

     Ebben a hónapban az előzetes tervek alapján sikerült többé-kevésbé megvalósítani a limit érték beállítására használható eszköztári elemet. Az implementálás során felszínre kerültek a rendszer egyes előnyei és hátrányai, melyek nagyban meghatározták a megvalósítás konkrét lehetőségeit. Mindenesetre elmondható, hogy a tervezettől így sem kellett nagy mértékben eltérni.
     Az első dolog az előző beszámolóban említett központi vezérlő osztály használatához kapcsolódik. Ez az osztály központilag tartalmazza az egyes, ezen osztály alá rendelt objektumok, többek között eszköztári elemek állapotait. Az állapotok lekérdezésének és beállításának a módja, konkrétan az azt megvalósító metódusok előre adottak. Ez egyrészről jó, mivel rávezeti a programozót a megoldásra, másrészről azonban speciálisabb problémák esetén leszűkíti a lehetőségeket. Esetünkben szerencsére elég egyszerű funkció bevezetéséről van szó, így ezek a korlátok csak érintőlegesen jelentkeztek. Nagy előnye azonban ennek a megoldásnak, hogy az általa támasztott szabályok betartásával a lekérdezés elmentése és betöltése nem igényel további kódolást, hiszen az említett lekérdező/beállító metódusok segítségével a rendszer automatikusan végzi azt el.
    A következő megemlítendő dolog a limit megadására alkalmas kombinált listát kezelő osztály, amit az egyértelműség kedvéért nevezzünk helyi vezérlőnek. A LibreOffice-ban elég általános, ha nem az egyetlen, az a megoldási mód, amit én is alkalmaztam. Ennek egyik jellemzője, hogy maga a létrehozott osztály teljesen különálló egységet alkot, tehát nem szükséges manuálisan összekapcsolni más osztályokkal, melyek kapcsolatba szeretnének lépni vele. Egyszerűen egy azonosítóval kell ellátni az osztályt, regisztrálni a megfelelő helyen és az így lefoglalt azonosító alapján lehet kommunikálni vele. Tehát a kommunikáló felek nem egymás metódusait hívják meg és az alapján adják át az információt, hanem tényleges címmel ellátott üzeneteket váltanak egymással, melyet a rendszer kézbesít.
       Ilyen csatorna köti össze a két vezérlő osztályt is és éppen itt derült ki a programozás során, hogy ez a csatorna csak részben két irányú. Ugyanis a helyi vezérlő bármikor küldhet információt a központinak, de az ellenkező irányban csak az állapotok inicializálása során történik átvitel. Esetünkben az ellenkező irányú üzenetküldésre olyan esetekben van szükség, amikor feltehető, hogy a központi vezérlő nem ismeri a legfrissebb limit értéket, pedig a következő művelethez erre szüksége van. Ekkor kell lekérdeznie azt a helyi vezérlőtől. Ezt végül a közösen használt eszköztáron, mint közvetlen csatornán keresztül oldottuk meg.
   Tehát egészében véve elmondhatjuk, hogy a rendszert jól megalapozták fejleszthetőség szempontjából, ami a LibreOffice esetében létfontosságú. Azonban az adatbázis-kezelő komponens, amelyet sikerült egy kicsit jobban felmérni, tartalmaz néhány kevésbé dinamikus területet. Előző beszámolómban előre vetítettem az adatbázis-kezelő SQL elemzőjének módosítását, mivel például a „TOP” kulcsszót nem ismeri fel. Egy kicsit jobban belemélyedve az elemző használatába kiderült, hogy az általa visszaadott elemzőfa (amit előzőleg egyszerűbb struktúrának neveztem) csúcspontjai statikusan épülnek fel, ami annyit tesz, hogy az adott csúcsok bármely SQL parancs esetén mindig ugyanazt az elemet (pl. a „SELECT” kulcsszót) jelölik, tehát az elemzőfa szerkezete valójában mindig ugyanolyan, annyi különbséggel, hogy az adott csúcs milyen adatot tartalmaz, illetve hogy egyáltalán tartalmaz-e adatot. Ez még nem jelent problémát, de ez a megoldás lehetővé tette, hogy egy elemet a csúcs sorszámával lehessen azonosítani és ez a gyakorlatban is így terjedt el. Ez azonban már nagyban megnehezíti a bővíthetőséget, hiszen egy újabb kulcsszó bevezetése egy újabb csúcsot jelent a fában, ami pedig – attól függően, hogy a sorban pontosan hova kerül – felborítja az összes eddigi sorszám szerinti hivatkozást.
       Azonban ez két dolog miatt sem jelent olyan nagy problémát. Egyrészről egyes módosítások elvégezhetőek az elemző közvetlen megváltoztatása nélkül is. Másrészről az elemzőt használó forráskód elég jól körülhatárolható, éppen ezért a jövőben egy vállalkozókedvű programozó viszonylag rövid idő alatt képes dinamikusabb formába átírni az elemzőfa használatát. Mindenesetre amíg ez nem történik meg addig a „TOP” kulcsszó bevezetését későbbre halasztjuk, hiszen ennek használatára egyébként sincs számottevő igény. Egyetlen esetről tudok, amikor szükség lehet rá, ha MS Access adatbázisfájlt szeretnénk kezelni LibreOffice-ban.
     A LibreOffice adatbázis-kezelőjének egyik legnagyobb előnye, hogy mindenféle adatbázis-motorhoz képes csatlakozni. Ez a fajta multifunkcionalitás azonban leszűkíti az adatbázis-kezelő lehetőségeit és funkcióját. Alapvetően egyfajta univerzális felhasználói felületként szolgál és így a tényleges végrehajtás, illetve az azzal járó ellenőrzések nagy mértékben a háttérben futó adatbázis-motorra tolódnak át. Éppen ezért a programozás során az egységes információlekérdezés, illetve az egységes metódusok használatának lehetőségei szűkösebbek és így a fejleszthetőség ismét csorbát szenved.
     Esetünkben például a „LIMIT” kulcsszó használatakor, ugyan az elemző felismeri azt, de az aktuális adatbázis-motor még dobhat rá hibát. Éppen ezért felmerült az igény, hogy differenciáljuk az új eszköztári elem használatát, és csak olyan esetben legyen elérhető, amikor az ténylegesen funkciónál is. Azonban az említett információlekérdezési hiányosságok miatt első körben ezt nem sikerült megoldani kielégítő módon, így az új funkció minden esetben elérhető.
  Összefoglalva részben sikerült leprogramozni a limit megadására alkalmas beviteli mezőt. Azok a felhasználók, akik az alap adatbázis-kezelőt vagy olyan adatbázis-motort használnak, mely ismeri a „LIMIT” kulcsszót, azok minden további nélkül használhatják ezt a funkciót. Az általános megoldás megalkotása mellett felmerült az igény arra is, hogy ne csak az eszköztáron keresztül lehessen elérni ezt a funkciót, hanem a menüben is kapjon helyet, melynek megvalósítása egy új menüből megnyitható felugró ablak formájában már folyamatban van.
     Ezúttal linkelem a megvalósítás kódját is, hogy lehessen látni a tényleges eredményt. Ugyan még nem fogadták el a beküldött módosításokat, de némi bővítés után ez is meg fog történni. Tehát a link: https://gerrit.libreoffice.org/#/c/1994/

Decemberi beszámoló – Limit

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

     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.

Szövegszerkesztés oktatóvideók a Szabad út projekt oldalán

toros, 2012. május 9. szerda

Elkészültek az FSF.hu Alapítvány Szabad Út projektjének keretében a LibreOffice Writer szövegszerkesztő használatát oktató videók. A korábban már bemutatott, a LibreOffice Calc táblázatkezelő, a LibreOffice Impress bemutatókészítő, valamint a LibreOffice Base adatbázis-kezelőt bemutató anyagokkal együtt így teljessé vált az irodai alkalmazások négy fő területével (táblázatkezelés, bemutatókészítés, adatbázis-kezelés és szövegszerkesztés) foglalkozó oktatási segédanyag. Az anyagok mindenki számára ingyenesen elérhetők, és szabadon felhasználhatók akár az otthoni önálló tanulásban, akár az iskolai tanórákon.

A videók a Szabad út projekt oktatóvideókat gyűjtő aloldaláról érhetők el.