Az élet úgy hozta, hogy eddig elkerültem a Joomla Form kezelőjének Checkbox típusát. A dolog első ránézésre szépen működik, de ha próbálgatni kezdjük az első mentést követően mindig bekapcsolt állapotú marad, és elsőre semmilyen szép szóval nem lehet kikapcsolt állapotra rábeszélni.

Tekintettel arra, hogy a mostani munkához szükségem volt rá, és kikerülni sem szerettem volna, ezért végigkerestem elsőre a weben elérhető dolgokat, majd a rendszert is megnéztem működés közben.

Az iránymutatást Posting Unchecked Checkboxes in HTML Forms cikkben találtam meg, ezt követően egyszerű vizsgálattal kiderült mi is a probléma. A HTML megközelítés szerint a checkbox csak akkor szerepel a POST-ban, ha az bekapcsolt állapotú. Amennyiben kikapcsoljuk, nincs benne a POST-ban. Ez gyorsan ellenőriztem is a beérkező modell osztályban és valóban a kikapcsolt vezérlő nem került be az érkező adatcsomagba. Néztem tovább mi is történik ezzel a csomaggal, és rá kellett döbbenjek, hogy a csomagban nem szereplő vezérlő értékét egyszerűen becseréli egy szimpla ‘1’ azaz igaz értékre a Table::Store működése során.

More »

Amikor az ember egy már meglévő kódhoz nyúl hozzá, két választása van. Van minden marad ugyan olyan mint addig volt és csak a mögöttes kódot cseréli, vagy teljesen újat alkot. A Joomla 3.2 átállás során ez a dilemma többször is előkerült, de a végén a teljesen új felületet alkotunk (az eddigi kezelési logika megtartásával amennyire lehet) lett a választás. Miért?

  • A front end felületen a régi rendszer nem támogatta a mobil eszközöket (2010-ben készült és nem volt még fókuszban).
    Az új rendszer teljesen új felületet kapott, ami egyrészt a Bootstrap-ra való átállásból, másrészt a mobil eszközök támogatását erősíti. Ugyan így erős igény volt, hogy a felület mobil barát legyen azaz, akár egy telefon pici (? az új eszközök mellett ez azért néha nevetséges mondás) képernyőjén is lehessen könnyen használni.
  • A back end felületen a Joomla projekt új design-re állt át. A J 3.2-vel megjelent admin felület már részünkről is elfogadható volt, kezelés, ergonómia, áttekinthetőség szempontjaiból, így ebből származtattuk a saját template-t. Az egyes moduloknak viszont – eddigi célkitűzéshez hasonlóan – teljesen egységesen kell besimulnia a rendszer kezelési logikájába, így a változtatás itt sem volt elkerülhető.
  • Az eddig eltelt időben – mint minden kódban – itt is elő-elő kerülnek sallangok, nem jó helyen implementált megoldások, amiket ennek kapcsán megpróbálunk elvarrni, megszüntetni. Ez számos esetben azt jelenti, hogy a front és back felületek most több ponton ugyan azt a kódot futtatják (hja kérem az évek meg a rutin megmutatja ezt hol és hogyan érdemes csinálni)

Miképp változik meg az admin oldalon a felület? Szerintem mára sikerült egy barátságos állapotot összehozni, íme:

eres_J25eres_J32

 

ui.: Több esetben megkérdezték már, miért örököljük le a rendszer template-t, miért nem használjuk rögtön azt. A tapasztalatom eddig az volt, hogy abban a pillanatban, hogy kicsit is igazítani kell a template-n (én legtöbbször az optimalizáció miatt szoktam), akkor a következő frissítés ne vágja haza amit csináltunk. Én bevallom, hogy a Joomla Admin oldalain a login képet előszeretettel módosítom, mert így sok oldal áttekintése esetén is tudom merre járok, az ügyfél meg élvezi, hogy “milyen aranyos így”.

joomla-32Mint írtam a napokban nekikezdtem a Joomla 2.5-ről átírni számos komponensemet az új Joomla 3.2 alá. Ennek keretében szeretném az eddigi tapasztalataimat megosztani:

  • a Legacy osztályokra való áttérés nem nagy ördöngösség
  • a ModellList osztály nem támogatja az eddigi módon használt OrderBy megközelítést, ezt módosítani kell
  • A JDate toMySQL() függvényét átnevezték toSQL()-re
  • azzal senki se kalkuláljon viszont, hogy az UI módosítás nélkül menni fog (azért ez érthető hisz Mootools –> Bootstrap áttérés történik)
    1. Az Administrator-i felületet érdemes újból átgondolni, az eddigi PNG állományok helyett CSS és webfontok kerülnek előtérbe
    2. A szűrések az eddigiekkel szemben másképp kerülnek megvalósításra, azokat a template-ből a View osztályba (nagyobb komponensek esetén általános felületre) kell átvinni. Ezzel tisztább és áttekinthetőbb lesz ugyan a template, de idő és munka
    3. A Batch megoldások önálló template-re kerülnek, ezekkel is külön foglalkozni kell
    4. Aki használta a különböző plusz Mootools könyvtárakat azokat is cserélni kell a template-kben és be kell tenni külön igény esetén ezek Bootstrap-es megfelelőjét
    5. Mindezek a FrontEnd felületen is előjönnek

Viszont a fentiek elvégzése után a kód működik, és eddig úgy fest az üzleti logikát nem kell módosítani. Ez viszont nagyon nagy dolog!

Én személy szerint örülök, hogy a szűrések kikerültek a templte-ből, mert így lehet egységesíteni egy-egy modulon belül és ezzel egyidejűleg a karbantarthatóság is javul. Jelentős problémának élem viszont meg, hogy az eddigi PNG alapú grafikai támogatást át kell állítani webfont-ra, amit SWG fájlból könnyű csinálni, de PNGből nem egyszerű és munkás. Épp ezért – külső tanácsra – megnéztem és azt hiszem használatba is veszem a http://thenounproject.com/ lehetőségeit.

Innentől kezdve azt hiszem lehet előre menni, már “csak” favágás, azaz nyomni kell, hisz “nyomják Krahácsot”.

joomla_roadmapLassan nyakunkon a Joomla! jelenlegi LTS verziójának cseréje, így neki kell kezdeni – ha morogva és zsörtölődve is – a régebbi modulok, komponensek áttekintésének, ki miképp támogatja az új verziót.

Nem látom értelmét elmélkedni a miért kell változtatni kérdésen, hisz a jelenlegi MVC architektúrát továbbra is támogatja a Joomla!, bár az új fejlesztéseket már érdemes a HMVC irányából megközelíteni, és abban elkészíteni (most még csak a szigorúan új fejlesztésekre gondolok). Igen ám, de mi lesz akkor az eddigi fejlesztéseinkkel? Miképp fogja azt a Joomla! 3.x támogatni?

More »