Alapértelmezett blokkrendszer kiváltása Context modullal? Érvek/ellenérvek?

Sk8erPeter képe

Sziasztok!

Huh, de rég jártam itt. :)

Olvastam egy igen érdekes felvetést az alapértelmezett blokkrendszer versus Context (+Panels) modulról itt:
http://www.slideshare.net/iztoksmolic/drupal2-15546254

7. USING DEFAULT BLOCKS SYSTEM
Use default blocks system only if project is very very simple.
A couple of attempts were made to improve block system, I bet on the following two:
Context, which is block system on steroids
Panels, introduces new block-like concept

A felvetés szerint tehát az alapértelmezett blokkrendszer helyett lehetne használni például a Context vagy Panels modulokat. Utóbbi (Panels) magára a megszokott blokkrendszerre nekem még mondjuk kevésbé világos. Ha valakinek van érve emellett, ne tartsa magában! No de térjünk vissza a Contextre.

A Context modulra jópárszor szükségem volt már, hogy az alapértelmezett, meglehetősen faék egyszerűségű beállíthatóságokon kívül plusz feltételektől is függővé tegyem adott blokk megjelenését, viszont mindig elég nagy kavarodást okozott az alapértelmezett blokkrendszerrel való felváltott/kombinált használata.

Tipikus probléma a blokkok elrendezése blokksúlyokkal: például adott smink adott régiójához beállítok blokkokat bizonyos súllyal az alapértelmezett blokkrendszeren keresztül (admin/structure/block), és ha a Context modullal szeretnék bizonyos feltételektől függően közéjük ékelni egy másik blokkot is, akkor mindkét felületen meg kell jelenítenem a blokksúlyokat, és akár manuálisan (NEM egérrel arrébbhúzással a célkereszt segítségével) kell ezt felülbírálnom... meglehetősen gáz megoldás. Ráadásul ha elfeledkezem erről, és a szokásos egyszerű módszerrel megváltoztatom a sorrendet (áthúzom a blokkokat), akkor felborul az addigi súlyozás, újból beállítja magának a számozást JavaScripttel, és akkor lehet újból beállítani ezt (ha elmentem).

Ettől függetlenül ha a Context UI-jal teljesen kiváltanám a blokkrendszert, akkor is fennállhatna ez a probléma: van context mondjuk 3 blokkhoz, és megint egy másik context létrehozva másik 2 blokk megjelenítéséhez, ekkor megint csak felmerül a blokksúlyok problémája.

Ez mondjuk számomra a legproblémásabb rész, de valóban elgondolkodtató, hogy minden blokkmegjelenítést az ember Context modullal szabályozzon (legalábbis egy modullal, egy helyen), főleg, hogy ez értelmes feltételek szabására is alkalmas.

De mi szól ellene? Vagy jut még eszetekbe érv mellette? (Itt is van cikk a kérdésről.)
Mi a véleményetek erről?

Köszönöm!

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
aruna képe

Huh, de rég jártam itt. :)

Elég off, de hogy lehetett így eltünni? Igazából azt hittem, valami lavina elkapott síelés közben. :)

Ha lenne ilyen díj, hogy az "Év legaktívabb fórumozója" vagy valami hasonló, a tavalyi évre biztos te kaptad volna.

A context-et nem használtam még.

2
0
Sk8erPeter képe

:D Köszi a nemhivatalos díjat :D Közbejött pár igen fontos dolog (pl. egyetemi dolgok, meló, magánélet), ami rendesen betáblázta a napjaimat, meg így a fórumfüggőségemet kicsit legalább sikerült csökkenteni (bár remegve :D) most végre ismét Drupalozom, lehet, hogy inkább a hsz.-lavina fog érkezni (már megint) :)

1
0
Sk8erPeter képe

Kicsit hosszúra nyújtottam a kérdést, az egész lényege tehát az, hogy mi a véleményetek a Drupal alapértelmezett blokkrendszerének a Context (+Panels) modullal történő teljes kiváltásáról?

Utóbbi (Panels) magára a megszokott blokkrendszerre nekem még mondjuk kevésbé világos.

Konkrétabban: feltételezem, a szerző a Mini panels almodulra gondolt, de ott a klasszikus értelemben vett blokksúly-rendezgetés és ilyesmik nem tudom, hogyan állítgathatók a klasszikus block UI (vagy épp a Context) kihagyásával (a megjelenítés feltételeinek állítgatása tiszta).

1
0
eager képe

http://balintk.com/pm/

Ez ^^ egy komplex csomag a Page Manager/Panelssel való ismerkedéshez. Itt a lap tetején lesz egy másfélórás videó, ustream-es, felvételről. Egyik nem sokkal ezelőtti budapesti Drupal User Group találkozón készült az IntegralVision irodájában. Alatta a slideshow, ami az előadás alapját képezte. Alatta meg egy interaktív esettanulmány.

Az előadás verziószáma 4.0 körül lehet (bár Bálint ezt pontosabban tudná eldönteni), igencsak kiérlelődött.

Ha érdekel a Drupal, és foglalkoztat, hogy a jövőbeli projektjeidnek milyen alapozása legyen - és hogy merre fejlődj tovább - akkor szerintem ez a csomag aranyat ér számodra.

...anélkül, hogy állást foglalnék bármelyik irány mellett. Az majd te eldöntöd. De az ilyen források, mint ez, azok jó ha megvannak ahhoz a döntéshez.

...és anélkül, hogy azt állítanám, hogy ez után a videó után azonnal egyértelmű lenne. Nem lesz az. Szerintem majd még fogsz kutakodni azért erre is, arra is. De az úgy a jó.

2
0
Sk8erPeter képe

Köszi a linket, nagyon hasznosnak tűnik! Mindenképp meg fogom nézni, hátha segít az eligazodásban. Kíváncsi vagyok, megválaszolja-e a szóban forgó kérdést, vagy csak újabb kérdéseket vet fel bennem, miután bizonyos részek tisztázódtak. :) Mindenesetre köszönöm!

0
0
aboros képe

2
0

-
clear: both;

Illyés Edit képe

Miért? Ez egy kis kiegészítő szolgáltatás a Panelshez. (Nem csak a $page['content']-et panelesíti, hanem az egész page.tpl.php-t kiváltja.) Én nagyobb webhelyekre mindig felteszem, hátha kell majd alapon, de szinte soha nem használjuk.

0
0
aboros képe

"Nem csak a $page['content']-et panelesíti, hanem az egész page.tpl.php-t kiváltja."

önmagában a panels modul szerintem nem sokat ér. pláne nem tudja önmagában kiváltani a blokkrendszert. ezért. hogy mekkora oldalnál "éri meg" az meg szerintem csak attól függ, hogy mennyire vagy vele barátságban. vannak akik egyátalán nem használnak hagyományos blokkokat, mert sok velük a macera. van aki azonnal panels everywhere segítségével panelesítik a mindent. de igazán nem akarok ám ezen sokat vitatkozni. ha az egész régió és blokkrendszert le akarod cserélni, kell a panels everywhere.

1
0

-
clear: both;

Illyés Edit képe

önmagában a panels modul szerintem nem sokat ér.

Hát ez egy elég húzós kijelentés. :)

Ha biztos vagyok benne, hogy a „körítés” (fejléc, lábléc) soha nem változik, akkor ami a kettő között van, arra elég a Panels, saját layoutokkal. A Panels Everywhere akkor jó, ha kell pl. a webhelyen belül egy microsite-szerűséget csinálni, ahol teljesen más a layout, mint a webhely normál részein.

„pláne nem tudja önmagában kiváltani a blokkrendszert”

A blokkrendszer összes szolgáltatása elérhető a Panels felületen keresztül. Meg mellette még mindenféle extrák: változók átadása, megjelenítési szabályozás, CSS #id és .class beállítási lehetőség, stb. Egy Panels webhelyen az ember jellemzően soha nem jár az admin/structure/block oldalakon.

0
0
aboros képe

de mondjuk hogyan szabod testre egy xy content type megjelenését csak panelsel? vagy én nem értek valamit vagy nemtom mi van. bekapcsolom csak a panels modult, kb semmire nem jó. bekapcsolom panel nodes modult, tudok létrehozni 'panel' típusú nodeot, húde hasznos :) aztán itt véget is ér a panels csomag.

minimum a page managert még be kell kapcsolnom, hogy bármi értelemeset tudjak a panelsel kezdeni. csak az meg nem a panels, hanem a ctools része, úgyhogy a kijelentésem egyátalán nem volt húzós, hanem pont igaz. önmagába a panels nem jó semmire se, pláne nem a blokkrendszer kiváltására.

0
0

-
clear: both;

Illyés Edit képe

Ezt írja a Panels modul felülete:

Create new...
Panel page
You must activate the page manager module for this functionality.

Tehát igen, be kell kapcsolnod a Page Manager modult ahhoz, hogy hozzáférj a Panels szolgáltatásaihoz. Nincs függőségként megadva, mert van egy kis funkció, ami a Page manager nélkül is használható. De amúgy kell hozzá, ugyanúgy, mint a Ctools… Viszont csak egészen extrém esetekben kell hozzá a Panels Everywhere.

0
0
Sk8erPeter képe

Köszi! :) Meg a moduljavaslatot is. :)
Nem ismerem a modult, de ki fogom próbálni. A README mondjuk azt írja,

Sites are best built from the ground up on Panels Everywhere. Converting an existing site may be quite difficult.

Azt viszont elfelejtettem jelezni, hogy már egy bejáratott, Zen-alapú, egyelőre fix 3 oszlopos (bal és jobb oldalsáv blokkokkal (!), középső, szélesebb hasáb az érdemi tartalmi résznek) oldalról van szó. Az admin/structure/block oldalon már rengeteg blokk van, a Context modullal is beállítottam már jópárat. Kódból és Views-zal létrehozott blokkok, már ha ez számít. (A Panels segítségével, mármint konkrétan a Mini panels-szel nem állítottam be még egyet sem.) Ez mondjuk egy elég fontos részlet, úgyhogy bocs, hogy ezt nem közöltem. Ezek átvariálgatása a linkelt modulnak megfelelően - amit egyelőre mondjuk még nem próbáltam ki, így nem tudom, milyen a gyakorlatban - valóban igencsak macerásnak tűnik első megközelítésre, belegondolva, mennyi blokkról van szó. Ilyen esetben is ajánlott lehet?

De mondjuk ha csak a Contextet akarnám használni, akkor is át kell variálgatni.
Igazából az a kérdés, mennyire éri meg.
Szenvedtetek már Ti is a blokksúlyokkal, amikről írtam? Tehát hogy egyik helyen ennyi a blokk súlya, másikon annyi, áthúzáskor megváltozik, van, hogy kézzel kell megadni, hogy stimmeljen a helyük a feltételektől függően, és így tovább... hogy szokás ezt szépen áthidalni?

0
0
Illyés Edit képe

A Contextet nem ismerem, a Panels esetén a régi Block felület teljesen elfelejthető, csak egy helyen kell mindent állítani.

Az égvilágon mindent meg lehet csinálni vele, épp csak kávét nem főz, viszont idő a megtanulása, a sok kattintgatás egy idő után elég fárasztó, kód szinten meg szinte átláthatatlanul komplex. A Block-kal ellentétben az ügyfél a Panels felületet egyáltalán nem tudja kezelni.

Csak olyan webhelyre javaslom, ahol nagyon sok blokk van, amelyeket nagyon sokféle feltételtől függően kell kirakni, környezeti változókat átadni nekik, stb. Egy átlag céges webhelyen nem éri meg használni.

3
0
Sk8erPeter képe

Köszi neked is az érveket!
Tulajdonképpen az érintett oldal esetében túl extra változások nincsenek általános oldalelrendezés tekintetében (fejléc, lábléc, két oldalsáv, középső hasáb általában ugyanúgy, ugyanakkora marad, egyelőre fix layout van csak), csak hogy a Panels Everywhere-rel kapcsolatos kommentedre is reagáljak egyben, inkább annyiban (ami a fontos a konkrét kérdésemet illetően), hogy bizonyos blokkok mely oldalakon jelennek meg, milyen feltételektől függően, és milyen súllyal, tehát melyik van feljebb/lejjebb, sőt, olyan is lehet, hogy egy blokk az X oldalon ilyen súlyú, Y oldalon megint más súlyú.

Na, ezekhez segítség a Context modul, mert különböző feltételektől függően tudom ezeket befolyásolni (szemben a default blokkrendszerrel, ahol a láthatóságot korlátozottan lehet állítani), de ez is azért macerás, ahogy leírt problémákból látszik - pl. hogy egyik feltételnél (inkább itt kontextusnál) ilyen súlyt állítok be, a másiknál meg olyat, de egérrel áthúzogatásnál átrendeződik ez a súlyozás, ezért van, hogy manuálisan kell megadnom a súlyokat... ez borzasztó kényelmetlen. Erre nem tudom, a Panels megoldás-e. Vagy éppen más.

A Block-kal ellentétben az ügyfél a Panels felületet egyáltalán nem tudja kezelni.

Az ügyfél egyáltalán nem fogja kezelni a blokkok elhelyezkedését, tehát jelen esetben ez nem szempont.

Csak olyan webhelyre javaslom, ahol nagyon sok blokk van, amelyeket nagyon sokféle feltételtől függően kell kirakni

Hogy mi számít soknak, az jó kérdés, de viszonylag "sok" van, többféle feltételtől függően, épp ezért untam meg, hogy kicsit kényelmetlen ezeket kezelni.
Igaz, már beállítottam őket nagyjából, de ha hozzá kell nyúlni, akkor könnyű elcseszerinteni például a súlyokat. Na ez lehet, hogy a Panels-nél is fennállna - de akkor konkrétan mire gondolsz, Mini panels kezelésére? Ott hogyan állítasz súlyokat ilyen áthúzós felületen? Csak mert írtad, hogy szinte kávét főz, de a blokkok kényelmes kezelésével én még nem találkoztam. Ami túl sok mindent nem jelent, mert bőven van mit tanulnom a Panels-ről.

1
0
Illyés Edit képe

Ahogy írtam, a Context-et nem ismerem, nincs összehasonlítási alapom.

A Panels tökéletesen megfelel arra, amit írtál. Hogy megéri-e, az csak utólag fog kiderülni. :) De legrosszabb esetben majd a következő projektnél fogod hasznosítani a megismerésére fordított időt.

A Mini panels arra jó, hogy több blokkot összefoghatsz egy csokorba, és a csokrot teszed ki egyik vagy másik panelbe egy meghatározott helyre. Egy-egy blokk tetszőleges számú csokorba bekerülhet. De nem muszáj a Mini panels-t használni, ez is csak egy kényelmi szolgáltatás, hogy kevesebbet kelljen kattintgatni. Például ha A, B, és C útvonalon külön-külön paneljeid vannak, de mindhárom esetben ki kell tenni az Aktív fórumtémák és az Új munkaajánlatok blokkot, akkor ezekből csinálsz egy minipanelt, és a minipanelt teszed ki a három panelbe.

A súlyokat az áthúzós felületen áthúzással állítjuk. :) Ha X útvonalon a blokknak z helyen kell lennie, Y útvonalon pedig w helyen, akkor két külön panelt készítünk, felvesszük a blokkot a megfelelő helyekre, és beállítjuk, hogy az első panel X útvonalon jelenjen meg, a második pedig Y útvonalon. (De persze lehet PHP kóddal és még sokféle megoldással operálni. Tényleg csak kávét nem...)

1
0
Sk8erPeter képe

Köszi szépen a szempontokat!
Most vitatkozni fogok, de nem azért, hogy veled vitatkozzak, mert egyelőre magammal is vitatkozom, hogy miket csináljak :D, hanem azért, mert nagyon jókat írsz mindig, amikor ellenvetéseim vagy aggályaim vannak, így biztos, hogy mindegyikre megvan a válasz - most kezdem kiismerni a Panels-t csak úgy igazán (hol vagyok még attól). Na meg kezdesz egyre inkább meggyőzni az egyre több előnyéről, de ezzel együtt sok hátrányát is látom a saját szempontomból (ezek nyilván informálatlanságból is következnek).
Ami miatt nagyon is érdekel, az az, hogy amit most alkalmazok az egyik oldalon, az a teljes káosz: a default blokkrendszer, a Context és a Panels modulok használatának egyvelege, épp feladattól függően - ezért döntöttem úgy, hogy na most már megemberelem magam. :))

A Mini panels arra jó, hogy több blokkot összefoghatsz egy csokorba, és a csokrot teszed ki egyik vagy másik panelbe egy meghatározott helyre. Egy-egy blokk tetszőleges számú csokorba bekerülhet. De nem muszáj a Mini panels-t használni, ez is csak egy kényelmi szolgáltatás, hogy kevesebbet kelljen kattintgatni. Például ha A, B, és C útvonalon külön-külön paneljeid vannak, de mindhárom esetben ki kell tenni az Aktív fórumtémák és az Új munkaajánlatok blokkot, akkor ezekből csinálsz egy minipanelt, és a minipanelt teszed ki a három panelbe.

Na, ez egyrészről jól hangzik, másrészről meg nem:

jól hangzik, mert

  • itt a mini paneleknél is meghatározhat az ember különböző feltételeket a kis blokk vagy akármicsoda (node, view, logó, szlogen, blabla) megjelenésére (attól függően, mit rakunk a mini panelbe),
  • meg ahogy írtad is, egybe lehet fogni akár több blokkot/tartalmat/akármicsodát, akár layout designerrel aztán fancy módon meghatározni a kinézetét, egy sor kódolás nélkül

rosszul hangzik viszont abból a szempontból (de szólj(atok) közbe mindenképp, ha rosszul értek vmit! :) ), hogy

  • ha jól értem, nem úszod meg a három panelbe bepakolást külön-külön (igaz, ez csak három kattintás az adott mini panelre, na de igazából három, teljesen szeparált felület), nem pedig mondjuk egy helyen határozod meg, hogy itt és itt engedélyeznéd a megjelenését (ez mondjuk a Context modulban vagy a default blokkrendszer kicsit buta "ezeken az oldalakon jelenj meg"-megoldásában megvan) - bár igaz, a mini panel létrehozásakor viszont meghatározhatsz korlátozásokat, amikor NE jelenjen meg (feltételhez kötés)
  • így nem látom egy helyen az összes blokkot, hogy mindig meg tudjam határozni, melyik kerüljön feljebb/lejjebb (súly), ahogy a default blokkrendszernél, aztán ezenbelül még tovább befolyásolni a feltételeket (vagy van ilyenre megoldás?) - a blokkok mindig tök külön felületen ("csokrokban") vannak, nincs egy átfogó felület (bár igaz, ha jól emlékszem, ez kombinálható a default blokkrendszer felületével, ahol akkor már a mini paneleket is tudod áthúzogatni)
  • csomó különálló paneled van, külön template-eket kell átdolgoznod, mindig valahogy szeparáltan látod a dolgokat, útvonalfüggőek a megoldásaid, ez igen kényelmetlen lehet
  • elképzelhető olyan eset, hogy például A, B, C blokk általában valóban egy csokorban van, viszont elképzelhető, hogy az egyik oldalon viszont pont a B és C blokk közé kell ékelni a D blokkot (ott épp megváltoztatni a súlyát), így ott A,B,D,C sorrendben lennének. (ez pl. Contexttel megoldható, de a fentebb említett kényelmetlenségek ott is felmerülnek)

A súlyokat az áthúzós felületen áthúzással állítjuk. :)

Igen, de mindig szeparált felületen, épp útvonaltól függően látod a blokkokat... :(

Ha X útvonalon a blokknak z helyen kell lennie, Y útvonalon pedig w helyen, akkor két külön panelt készítünk, felvesszük a blokkot a megfelelő helyekre, és beállítjuk, hogy az első panel X útvonalon jelenjen meg, a második pedig Y útvonalon.

Mondjuk ez asszem pont felelet az előbb utolsó felvetett szempontomra. De itt is külön-külön panelnél kell állítgatni, brühü.

Persze lehet, hogy túldimenzionálom a problémát, de azért a default - sajnos buta - blokkrendszer esetében legalább az egy kényelmes dolog, hogy tényleg minden blokkot láthatok egy helyen, kényelmesen át tudom húzni egyiket a másik fölé/alá, meg tudom határozni azok sorrendjét.

Amúgy pont találtam egy egész jó kis slide-ot a téma kapcsán a Lullabot egyik fejlesztőjétől:
http://www.slideshare.net/davexoxide/drupal-blocks-vs-context-vs-panels

Idézek:

PANELS vs CONTEXT

PANELS

Pros

  • Powerful
  • Point-n-Click
  • Not dependent on template
  • Content/Context aware
  • Caching

Cons

  • Path dependent
  • Complex UI

CONTEXT

Pros

  • Powerful
  • Point-n-Click
  • Content/Context aware
  • Simple UI

Cons

  • Abstract
  • Limited layout options

When should I use Panels?

  • Client or site-builders need to move content around
  • Complex page layouts
  • URL structured layouts
  • Variants – gives more flexibility

When should I use Context?

  • Developer driven site
  • Theme provides enough regions
  • Context Layout – gives more flexibility
  • Context driven layouts
0
0
Illyés Edit képe

Igen, a Panels egyik hátránya a széttöredezett UI. Elvileg lehetséges, hogy nem töröd szét az admin felületet, hanem mindent egy helyen csinálsz, és PHP-kóddal szabályozod az egyes oldalelemek láthatóságát, mikor melyik változót kapják meg, mikor melyik layoutot használják, stb. De akkor meg felesleges a Panels, írj egy modult és kész.

Általános probléma, hogy ha van egy 10 különböző layoutot használó, 50-100 blokkot mozgató webhelyed, akkor nem tudod jól átlátni. Akár Panels-szel dolgozol, akár saját kóddal. Erre én saját kis chartokat, Excel táblázatokat és efféléket szoktam készíteni magamnak, de azokat naprakészen tartani megint csak plusz munka.

Drupal 8-ban az egyik fő fejlesztési irány a blokk rendszer kiváltása, de nem teljesen Panels irányba ment el a fejlesztés. Lehet, hogy már van valami kísérleti modul, én sajnos nem tudtam követni a fejleményeket az utóbbi időben.

0
0
Illyés Edit képe

Az viszont általános szabályként megfogalmazható, hogy akár Panels, akár Block + Context, akár saját kód, csak az egyik féle megközelítést érdemes használni. Ha többfélét keverünk, annak az az eredménye, hogy az ember fél munkanapja azzal megy el, hogy keresi, hogy ez vagy az a beállítás most éppen melyik modul fennhatósága alá tartozik. :)

1
0