Az új verzióban létezik egy munkafolyamat vezérlő mag, mely grafikus szerkesző felülettel is rendelkezik. A működésről részletesebben később, előljáróban annyit, hogy Petri hálózatok készíthetők, és ezek működtethetők. A hálózat tranzícióihoz lehet folyamatokat rendelni, és ezek alapján áll össze a workflow.
És előbb-utóbb talán minden lényeges elem bekerül a dokumentáció kézikönyvi (tutorial) részébe...
A zefext projektoldalán letölthető az új verzió.
Az online dokumentáció is elérhető, és a beígért módon az ExtJs dokumentációval együtt került kihelyezésre.
A karácsonyi 3.1.0 megnyerte a tetszésemet és el is fogadtam, mint alapverziót a zefext-hez. De hamar váltanom kellett a 3.1.1-es javításra, mert a chrome esetében az űrlapok nem működtek megfelelően. Az {url: 'valamilyen-url'} hibásan került feldolgozásra, és a form action attribútum értéke egy objektum lett, pontosabban egy objektum hivatkozás szöveges reprezentációja: <form action="{object ...}". És így persze nem működött.
Elsőként azt hittem hogy én szúrtam el...
Akkor még a régebbi chrome verzió volt fenn, amelyben nem voltak olyan fejlesztőeszköz lehetőségek mint a legújabban.
Megint pörögtem mint a foxikutya...
De megoldódott:
És így is lett.
Régi vágyam, hogy a zefext dokumentációt és az ExtJS dokumentációt egybeforrasszam. Sikerült. Át kellett írni hozzá a phpdocumentor egy sablonját, valamint a phpdocumentor forrásfájljait is (csak kis részben), és az ExtJS dokumentáció index.html és docs.js fájlokba is bele nyúltam. Ez utóbbiakba tényleg csak egy picit. Ennek köszönhetően a zefext dokumentáció része lett az ExtJS dokumentációnak, viselkedése azonos, megjelenési stílusa egy kicsit más - de azonos szellemiségű. A következő verzióban már ez található meg, valamikor a tavasszal. Addig egy kis ízelítő (nem photoshop):
Kb. egy év volt amíg rászoktam a fejlesztés közbeni folyamatos (inkább szakaszos) dokumentálásra. Természetesen midig fő vágyam volt, hogy a duplamunkát kerüljem, illetve, hogy a fejlesztés és dokumentálás egy helyen történjen. A PHP-hez a csodálatos phpdocumentor nagyon nagy segítség volt. Ezzel sokmindent meg lehet oldani. Ám van amit nem. Az adatbázis szerkezet illetve kapcsolatok terén más megoldások léteznek. A powerdesigner ihlette meg azonban azt a rendszert amit a zefext esetében használok. Mivel kifejezett mániám, hogy a dokumentáció és maga a rendszer egyként éljen, így olyan modult készítettem ami nemcsak az adatbázis dokumentációja, de egyben a rendszer működési alapja is. Az adattáblák közötti kapcsolatokat külön adattáblában tárolom, és ezek alapján készít a rendszer automatikus táblanézeteket, összefűzéseket. És ennek mellékterméke az a grafikus felhasználói felület, ahol ezeket menedszelni lehet, illetve képernyőképként elmetve, vagy akár online dokumentációként szolgálnak.
...méghozzá a 3.1.0 ExtJs verziót. Már próbálgatom.
Hellókarácsony!
A zefext projektoldalán letölthető az új verzió. A zefexttől a fa alá...
...karácsonyra.
Ez már tartalmazza az attribútum menedzser modult. Attribútum kezelés, függőségek beállítása. Teszt adatok. Egyelőre ennyi.
Bár már megvan a továbbfejlesztés iránya is: keresés, szűrés, lekérdezések...
A rendszerben készül egy alkotórész, egy motor, amelyik attribútumok menedzselésével foglalkozik. Feladata az attribútumoknak (jellemzőknek) és a közöttük lévő összefüggéseknek a nyilvántartása. Illetve, hogy a rendszer bármely eleméhez kapcsolni lehessen őket.
A modul alapvetően az attribútumok adatbázis elemekhez kötését oldja meg. Ezen kívül ha a jellemzők között összefüggések definiáltak, akkor azok létezését illetve nemlétét lehet szabályozni. Például a cipőméret-tartomány függ attól, hogy milyen nemű az illető. És egy termék típusától függ, hogy súlyra vagy darabra mérjük. Mindezek attribútumai az adott dolognak.
Hol lehet ezt használni?
Minden olyan táblában, ahol együtt vannak tárolva különböző dolgok. Például egy raktár termékei, egy gyár terméklistája, egy étlap elemei vagy egy webáruház kínálata. Teljesen különbőző jellemzőjü dolgokat kell egy rekordszerkezetben tárolni. Ezt hivatott megoldani a modul.
Kezdem Ádám-Évától. SQL92. Ez már sejtetni engedi, hogy valamiféle SQL különbségekről van szó. Hát igen. Mivel keretrendszert készítek, így cél az, hogy több adatbázis típust ismerjen. Egyelőre a MySQL és a PostgreSQL a kitűzött cél. Jómagam a rugalmas rendszereket és nyelveket szeretem, ezért kezdtem el a PHP-vel is foglalkozni. A kezdetekkor az ingyenesen hozzáférhető adatbázisok közül az M betűs előbb szerepelt az ábécében, mint a P betűs. Igy a MySQL lett az amelyikkel éveken át dolgoztam. Sok hátrányát, mely területeken a PostgreSQL előnyt élvez, azokon a programokon amin dolgoztam nem éreztem. Ám mindkettő fejlődött tovább az évek alatt, és hamár a Zend Framework kezeli őket, hát én is léptem. A PostgreSQL nagyon megtetszett, és még koránt sem használtam ki a lehetőségeit. De sajnos a két rendszer közötti külőnbségek sokszor bosszantanak. Ugyan a Zend Framework rendszer szinten kezeli mindkettőt, ha a rendszer select építőjét használom, ám az nem mindig elég.
CASE mezo_1
WHEN 1 THEN mezo_string
WHEN 2 THEN mezo_integer
WHEN 3 THEN mezo_date
END AS mezo_ertek
A fenti példában a PostgreSQL előre meghatározza az eredménymező típusát. Mivel itt különböző típusúak lehetnek, ezért reklamál. A MySQL nagyvonalú eleganciával visszaadja amit várok. A PostgreSQL esetében kell egy kis trükk. Ha hozzáfűzök egy kis szöveget, mondjuk a semmit, akkor már minden mező szöveges.
CASE mezo_1
WHEN 1 THEN mezo_string || ''
WHEN 2 THEN mezo_integer || ''
WHEN 3 THEN mezo_date || ''
END AS mezo_ertek
Így már jó, csak a MySQL nem így fűz össze. SQL92 nesze-neked.
CASE mezo_1
WHEN 1 THEN mezo_string %pgC%
WHEN 2 THEN mezo_integer %pgC%
WHEN 3 THEN mezo_date %pgC%
END AS mezo_ertek
A %pgC% sablon érték már SQL típustól függően változtatható, csak emiatt kellett írni egy sablon értelmezőt is. Grrr...
Keresgéltem a neten mindenféle css alapú sablonokat. Hamár valaki megírta, és opensource, akkor be is lehetne építeni a rendszerbe. Átnéztem joomla, wordpress és egyéb sablonokat, sok jó volt köztük, de egy sem tudta azt, hogy csak a css változtatásával változik az oldal kinézete. A különböző elrendezésekhez, sokszor küönböző html forrás is kellett.
Aztán rátaláltam a LayoutGala oldalára. Itt 40 különböző elrendezés van kidolgozva ugyanazon html forráshoz. Minden elrendezés az alábbi elemekből áll:
Szerencsére ugyanez a tartalmi minta az extjs borderlayout példájában is létezik. Ezután jött az ötlet, hogy a css sablont részekre kell bontani. Három külön css fájl adja ki a végső kinézetet:
Az elrendezést a LayoutGala alapján dolgoztam ki. 40+1 elrendezési sablon áll rendelkezésre. A plusz egy az az extjs dinamikus elrendezése, az elrejthető és átméretezhető panelokkal. A színezésben csak a színdefiníciók és háttérképek meghatározásai vannak. Az egyéb stílusjegyek pedig a szövegformálás, bekezdések, keretezések, H1, H2, H3, H4 elemek, linkek, stb. stílusdefinicióit tartalmazzák, szín meghatározás nélkül. Így a végső eredmény a három meghatározás kombinálásával adható meg. Jelenleg 41*3*2=246 megjelenési forma létezik. Az előzetes tesztelés bíztató, így ezt az irányt viszem tovább a fejlesztésben.
Az online dokumentáció elérhető a SourceForge.net oldalán.
Elkészült. Zefext demo elérhető a sourceforge oldalán.
Nosza rajta.
A sourceforge oldalán jelenleg a működés közben látható DEMO beüzemelése folyik. Remélhetőleg pár napon belül elkészül. A sourceforge bíztosít:
A kezdeti jelek bíztatóak, bár már futottam bele olyan hibákba, amit az eddigi tesztkörnyezet nem jelzett. A Zend Framework és a Smarty már fentvan.
Tervek szerint a demo tartalmaz majd egy látogatói és a readonly-adminisztrátor hozzáférést a nyilvánosság számára.
Tesztelhető lesz általa a rendszer alapműködése, a jogosultságkezelés, az RDBMS funkcionalitás és az ExtJS GUI.
A zefext projektoldalán letölthető az új verzió.
A letölthető fájlok csak egy-egy részmodul vagy funkcionalitás fejlesztése után frissülnek.
Az svn forrás akár napi szinten is változhat.
Ez a bejegyzés önreklám. Mondhatnám, hogy leírás, kivonat, stb. De nem. Ez a szöveg bizony a releváns találatok okán született. Ugyanakkor valóban leírás is.
Egy továbbfejlesztett keretrendszer, melynek alapja a Zend Framework, és az ExtJS. Ezt a kettőt hivatott ötvözni. Olyan rendszer, amely a PHP oldalán képezi azokat a javascripteket, amelyek minimum szükségesek a böngésző oldalán a megfelelő ExtJS objektum létrehozásához. A cél: könnyed, egyszerű programkód írás, a tetszőleges bővítési, paraméterezési lehetőségek meghagyásával.
A Zefext a Zend Framework rendszer bővítése, mely a keretrendszertől elvárható alapfunkciókat tartlatmazza: felhasználókezelés, jogosultság kezelés, be és kiléptetés, regisztráció. Driver jellegű funkcionalitás az ExtJS GUI és az adatbázis kapcsolat.
Jelen verzióban a PostgreSQL és a MySQL támogatott.
Szintén cél az adatbázis valódi RDBMS-ként való kezelése. Olyan relációs adatkezelés, amely a nem relációs (pl.: MYISAM) adatstruktúrában is működik. Sőt ennél több. Mert nem a kapcsolódás az egyedüli lényeg, hanem a hivatkozott adat automatikus megjelenítése is. Például ha egy adatmező egy típusra annak azonosítójával hivatkozik egy másík szótártáblában tárolt adarta, akkor annak a táblának a reprezentációs értéke jelenik meg a hivatkozás helyén. A reprezentáció lehet az adott tábla bármely mezője, vagy annak kombinációi. És mindezt az ExtJS lehetőségeivel tárni a felhasználó szeme elé, és annak widget-jeivel kezelni, módosítani, stb...
Szeretem. Rugalmas. Fejlődik. Bár minden nagy verzió után dobok egy hátast. Nincs lehetetlen. Programnyelv a javából. Többet a PHP oldalán.
A Zend terméke, PHP keretrendszer számos lehetőséggel. Folyamatos fejlesztés alatt áll. Én csak egy éve ismerem, de számos dolgot használ, amit megírtam volna magam. Így nem kell. Munkamenet, adatbáziskezelés, hitelesítés, stb. (session, database, authorization, etc.).
Az ExtJS egy javascript alapú rendszer. Böngészőoldali, javascript alapú GUI. Alapkönyvtár + widgetek. Famenü, menü, tabok, űrlap elemek, div ablakok, vidd-dobd, stb. (tree, tab, menu, from, window, drag-drop, etc.).
Csak egy pár mondat.
Fejlesztés: egy windows környezeten és egy linux környezeten. És a linux kell. Miért? Segít fellelni a bugok egy részét. A windows elegánsan elsiklik a kisbetű-nagybetű probléma mellett. A linux nem. Legyen szó fájlnévről, osztályról vagy metódusról.
Windowson fut, a linuxon meg nem. Debug. "case" hiba. Már meg is van a bug. Javítható.
Még a mai napig belefutok ilyenekbe.
Már korábban próbálkoztam az eclipse fejlesztői környezettel. Elég nehézkes volt megszokni, mert előtte volt alkalmam a Zend Studio-val dolgozni. Sok hasonlóság van, de máshol vannak bizonyos menük, mások a billentyűparancsok, stb. Akkor dobtam el magam amikor a {} és [] gépelése közben az alt billentyűkód bekavart, és mindig valamit csinálni akart, ez általában nem ment és jött a felbukkanó hibaüzenet. Persze amit írni akartam az meg sehol.
Úgy látszik valami megváltozott. A legújabb PHP-re konfigurált eclipse már egész jól megy. Annyira hogy áttértem. Egyedül a | jel kavar be, és a billenyűparancsot sehol nem tudom kikapcsolni hozzá. Egy listában mutatja az aktuálisan hozzárendelt funkciót, de a konfigurációban, ahol ki tudnám kapcsolni, ott már nem szerepel. Mivel csak ez az egy bajom volt eddig, így megjegyeztem az alt + 124 -et. De áttértem. Miért is?
Mert a kódkiemelés, kódfelkínálás, kódsablonok úgynúgy megvannak mint a Zend-ben, de plussz szolgáltatások is vannak.
Ezek már meggyőztek. Ráadásul ingyenes és fejlődik.
A címben szereplő nevet adtam annak az osztálynak, mely a könyebb fejlesztés miatt született.
Az ExtJS viszonylag komplex objektumokat használ, melyeknek számtalan konfigurációs paraméterezési lehetősége van. Egy általános keretrendszer azonban az alapértelmezett értékekkel (PHP oldalon) tökéletesen működhet, és finomítani a beállításokat ráér azokban az esetekben amikor szükséges. Emiatt készült egy jópár osztály-metódus, amelyik paraméterként csak a legfontosab változókat kéri. De akkor mi van a finombeállításokkal? Az első változatban egy változóval kiegészült az argumentumlista, melyben mint asszociatív tömbben, bármilyen adat átadható a metódusnak. Így a tömbkulcsok - változóval való megfeleltetése a függvényen belül már tetszőlegesen megoldható.
És itt jön az EasyParameter. Nem tömb kerül átadásra, hanem egy objektum. Ennek vannak paraméterei. Az elv ugyanaz, de a fejlesztés könyebb. A metódusban megadható, hogy melyik leszármazottat várja a program, és fejlesztés közben a kódkiegészítés már kijelzi, hogy az objektum milyen paraméterekkel rendelkezhet - szemben az asszociatív tömbbel, amelyik erre nem képes. Plusz még egyszerűbben dokumentálható.
/**
* Absztrakt alaposztály
*/
abstarct class EasyParameter
{
}
/**
* Konkrét kiterjesztése egy paraméterosztálynak
* a szükséges változókkal
*/
class EasyParameter_ForSample extends EasyParameter
{
public $piri;
public $para;
}
/**
* Valamely ExtJS objetkumot felépítő gyorsosztály
*/
class MyClass {
/**
* Metódus, mely már a konkrét paraméterosztályt várja
*
* Legyen például a metódus egy grid megjelenítő
* a két fontos változó pedig a div amelyikbe a grid kerül
* és az url ahonnan az adatot fogja az ajax bekérni
*
* és itt jön a tetszőleges utolsó paraméter
* melyben megadható bármely egyéb adat:
* magasság, szélesség, szín, szag, stb.
*/
public function myMethod ($important_1,
$important_2,
EasyParameter_ForSampe $parameterObject = null)
{
// itt jön a kód, mely már könnyedén használja
// a paraméterosztályt
}
}
A fentiekhez hasonló elven működik az ExtJS-ben a configObject.
{title: "cím", height:35}. Úgyhogy nem is spanyolviasz.
Az ExtJS filozófiája szerint a globális névteret nem illik összeszemetelni. Hát emiatt most elkezdtem átírni a javascripteket.
Habár a fejlesztés eddig egyedül ment, mégis ráálltam a verziókövetés útjára. Hogy ez rögös lesz-e vagy sima, azt a jövő eldönti. Életemben most csináltam ilyet először. Két nap foxikutya után már eredmény is van. 48 óra szösszenetei:
A zefext forráskód változatok a sourceforge oldalán követhetőek nyomon:
A mai nap az alábbi problémán hörögtem mint egy foxikutya:
Fájlfeltöltés >>> Zend_File_Transfer_Adapter_Http.
Mime szerinti szűrés >>> addValidator('MimeType' ...
mime type: image/jpeg és image/png
Firefox: OK
Chrome: OK
Opera: OK
IE: ---
Namost milegyen?
Egy későbbi posztban majd megemlékezem a jsonviewer.stack.hu nyomozásomban tett sikereiről, úgyanis ennek segítségével bármilyen tömböt, objektumot amit át tudok küldeni a böngészőnek, szemnek is emészthető formában adja vissza.
És hamár az explorerhez nincsenek profi és ingyenes "firebug" szerü eszközök, a firefox ie tabnál meg a firebug nem működik, hát akkor jön a gyalogmódszer.
Szépen visszafejtettem a feldolgozás folyamán használt összes kapott adatot. Hát mit csinál az ie? Különcködik. Szerintem mindenkinél okosabb.
mime type: image/pjpeg és image/x-png.
Heuréka!
Ui: Ez legalább rákényszerített, hogy egy komplexebb mime ellenőrzést készítsék, elővegyem a hivatalos doksik alapján készült mime listákat...
Ajánlom: ExtJS Blog.
Jómagam is rendszeres olvasója vagyok. Lehet belőle tanulni.
A jelenleg fejlesztés alatt álló pre 1.0 alpha verzióhoz szükségesek:
A fejlesztés windows XP és linux CentOs alatt folyik. A feljesztésbe bevont adatbázis rendszerek: MySQL 5.0 és PostgreSQL 8.3.
A teszteléshez Firefox 3, IE 8, Chrome 1 és Opera 10 használt. Bár néha a firefoxon kívül a többit dobnám.
A Zefext egy keretrendszerre épülő kibővített keretrendszer. Na ez így elsőre kicsit zagyva. Akkor részletesebben:
Tehát egy olyan rendszer amelyik a Zend Framework szerveroldali lehetőségeit ötvözi az ExtJS kliensoldali lehetőségeivel, megfűszerezve egy kis felhasználóbarát funkcionalitással.
Utolsó kommentek