Ez egy olyan téma, amiről már megint régen készültem írni, és most újra egy drupal.hu kérdés adta a végső lökést.
A feladat:
ne csak a meglévő lehetőségek közül lehessen választani a közzétételi beállításoknál (közzétesz, címlapra helyez, kiemelt), hanem legyen egy plusz checkbox is
Ez egy nagyon egyértelmű és jól behatárolt leírás. A kulcsszó, amit a szerző is nagyon jól megfogott, a közzétételi beállítás, magyarul node options.
Honnan vannak ezek az opciók?
Ezek egy node különböző állapotai, ami lehet igaz vagy hamis. Ezek az opciók a node táblában vannak eltárolva egy-egy mezőben. Tehát a feladat akkor van teljesítve, és nem túlteljesítve, ha ezt, és csak ezt meg tudjuk valósítani.
Szerencsére nagyszerű jószág ez a drupal, ezerféleképpen meg lehet csinálni egy dolgot, és ez a feladat nagyon jó példa arra, hogy megoldás és megoldás között is van lényegi különbség. Nem mindegy ugyanis, mennyi erőforrásba kerül amit választunk.
A fórumban a következő lehetőségek merültek fel:
- CCK - ezt ketten is írtuk
- Flag - nekem az egyik személyes kedvencem
- Taxonómia
- Célmodul - ezt időközben megtaláltam: Custom Publishing Options
Drupalban baromi könnyű "overkill" módon kivitelezni dolgokat, ez természetes is, hiszen a jól bevált, egyszerűen kivitelezhető eljárások adják magukat, viszont felesleges terhet rónak a rendszerünkre, ergo sok olyan funkcionalitás "keletkezik" magától, amire semmi szükség a feladathoz.
Az ilyen overkill megoldások halmozása vezet odáig, hogy lesz egy batár nagy rendszer, ahol 1s helyett 4-5s az oldalgenerálási idő, a szolgáltató ledobja a láncot, és visítva szalad el, ha drupal oldalt akarnak nála üzemeltetni.
Menjünk végig a megoldásokon, és nézzük, minél, mivel lövünk túl a célon:
CCK
Lesz egy csomó sosem használt, feleslegesen tárolt beállítás, egy plusz mező egy egészen más táblában, megjelenítési módonként egy-egy sosem használt megjelenítés beállítás, egyéb moduloktól függően több felesleges változó, D7-ben pl két új táblát is kapunk ajándékba.
- Mikor lesz jó nekünk a cck?
- Akkor, hogyha ezt az értéket valamilyen módon ki akarjuk íratni a nodeban.
- Akkor, ha ki akarjuk használni a mezők súlyozásának a lehetőségét.
Flag modul
Na ez elég összetett dolog, amiért a leginkább ellenjavallt, hogy erősen a node műveletekbe épül bele a saját lekérdezéseivel, tehát akkor is terheli a nodeot, ha az adott nodenak semmi köze egyébként flaghez. A sminkrétegbe is belemászik, a viewsba, szóval mindenbe, amit egyébként sosem használnánk belőle ehhez a feladathoz.
- Mikor kell flag modul?
- Akkor, ha ezt a státuszt pl a node szerkesztése nélkül egy szexi ajaxos widgettel kell állítani.
- Ha rules-al kombinálva folyamatvezérlést építünk.
- Ha például az egyik role az egyik állapotot, a másik a másikat állíthatja, pl egy editor beállíthatja "flagged"-re, de csak egy administrator állíthatja "unflaggedre"
Taxonómia
Összességében a legdrágább megoldásnak tűnik. Ez az egy érték 2 táblából érkezik ráadásul db_rewrite_sql-el, ami azt jelenti, hogy más modulok is simán fűszerezhetik lekérdezést.
Keletkezik továbbá két _publikus_ listaoldal is, márpedig igen valószínűtlen, hogy a látogatónak mutatnunk kell külön oldalt nodeokkal a lehetséges értékekről.
Lesz még tovább egy plusz szótár a maga összes sosem használt feauturével, benne két termmel, aminek az értékét nem fogják változtatni, mindezekhez saját beállítóoldalak.
A node megjelenítésébe bekerül automatikusan az érték - lehet a saját hookjainkal kiszedni.
Ezeken kívül itt van d6 régi baja, hogy x mennyiségű szótár után megbolodnul a szótár súly rendszere, önálló életet él, függetlenül attól mi van beállítva.
- Mikor kell a taxonómia?
- Ha kell saját automatikus listaoldal a fontos nem fontos tartalmaknak.
- Ha a lehetséges értékeket bővíteni, rendezni, módosítani kell.
Célmodul
A célmodulunk ezekhez képest éppen annyit tud, amennyire szükség van. Hozzáad egy mezőt a node táblához, biztosít egy jogosultságot, hogy melyik role szerkesztheti, és egy views integrációt, illetve beteszi magát a node formba.
Ha jól átgondoltuk, hogy tényleg nem kell több "feature", és egészen pontosan ez az, amit meg akarunk valósítani, akkor ez lesz a jó választás.
Ez a poszt igencsak ráült erre feladatra, pedig eredetileg sokkal általánosabban akartam írni az "overkill" jelenségről. Viszont maga a feladat annyira egzakt, hogy csak jóval elvontabb és általánosabb példát tudtam volna írni.
Hozzászólások
Üdv Ezek szerint ezzel azt
Üdv
Ezek szerint ezzel azt mondod, hogy egy célmodul amit pluszként töltünk fel hatékonyabb lehet a core CCK megoldásánál.
Én még jelenleg a feladataimhoz inkább célmodulokat keresek, de sokszor az az érzésem ezzel csak fogyasztom az erőforrásomat amit a tárhely ad.
Így sokszor válaszom azt hogy a fent lévő modulok közül mivel lehet még mást is megoldani, magyarul dolgoztatom őket..:), de lehet újra kéne gondolnom?!
Minden esetre gondolat ébresztő volt a poszt köszi.
Ebben az esetben nem a
Ebben az esetben nem a modulok darabszáma számít, hanem a funkcionalitása. Nem az használ jelentékeny erőforrást, hogy fenn van egy modul, hanem hogy hogyan valósítja meg a feladatot.
Azért elég sok minden bejátszik még a döntésben, pl van ez a field permission dolog, amikor mezőszinten kell jogosultságokat kezelni. Azzal pl úgy vagyok, hogy 2-3 mezőig még lekezelem én saját modulból pár sorral, ha már többről van szó, inkább felteszem a field_permissiont, hogy átláthatóbb legyen a munka.
Szóval nem egy egzakt mutatvány ez, ezért is emeltem ki, hogy ez a példa baromi jó, mert nagyon pontos és világos a cél. De más feladatnál más szempontok is képbe jöhetnek.
Hozzászólás