Display Suite versus Panels ... egyik/másik/mindkettő? (Van egyáltalán értelme mindkettőnek?) A Display Suite kidobható?

Sk8erPeter képe

Sziasztok!

Az alapértelmezett blokkrendszer kiváltásáról szóló téma kapcsán elég sok plusz információt tudtam meg a Panels modulról, és elkezdtem még jobban felfedezni, kinyitotta a csipámat. Egyre több lehetőséget látok benne, és úgy érzem, egyre inkább ki kéne iktatni a bizonyos értelemben hasonló célokra alkalmas modulokat (mivel ez igen jelentősen növeli a Drupal erőforrás-igényét). Ekkor jön a képbe a Display Suite.
Ha az ember intenzíven használja a Panels-t, rendesen ismeri, úgy képzelem el, hogy a Display Suite kidobható, mert a layoutok létrehozására és módosítására, a felületen látható elemek átrendezésére kényelmesebb módot kínál, plusz elemeket, mint a node címe, beküldés dátuma és hasonlók, a Panels-zel elvileg szintén hozzá lehet adni, plusz még egyebeket is... DE a Display Suite-tal lehet létrehozni code fieldet, dynamic fieldet, block fieldet preprocess fieldet az admin/structure/ds/fields útvonalon. Vagy ez is kiváltható lenne?

Milyen szempontokról feledkezem meg? Mi a véleményetek a kérdésről?
Mi szól a Display Suite mellett, ami miatt nem dobható ki adott esetben?
Igaz, más a megközelítése a két modulnak a layoutok átszabására, de az alapvető cél eléggé hasonló.

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

Erre nincs egzakt válasz, ahogy jólesik. Kidobható (elvileg), de én szeretem, és megszoktam a ds szolgáltatásait, a build modeok kényelmes kezelését, a 100% html kontrollt - és nem jön rosszul, ha netán views templatet kell faragni.

Továbbá nehézkesnek tartom panelsszel egy sokmezős entitás megjelenését felépíteni, hiszen az első etap az kb egyesével marha sok kattintással összeszeded a mezőket, na erre nekem jobban bejön a klasszik huzivoni mezőbeállítós cucc.

Tehát nálam ha tpl level szinten nézzük, akkor node.tpl.php = ds, rengeteg build mode-al, és a build modeok vannak használva rendered entityként panelsben, viewsban, etc.

Természetesen előfordult, hogy node type full content oldala panels-szel készült, mivel három különböző arca volt a node-nak, más kellett a tulajnak, más egy bejelentkezett felhasználónak, és anonymnak.

A performance miatt no para, egy entitycache, és kb teljesen semlegesítve van.

1
0

----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.

Sk8erPeter képe

Köszi a választ! És bocsánat, hogy csak most reagálok!
Hasznosak voltak a megjegyzéseid, pár plusz szemponton elgondolkodtatott, ami még nem jutott eszembe a téma írásakor.

Továbbá nehézkesnek tartom panelsszel egy sokmezős entitás megjelenését felépíteni, hiszen az első etap az kb egyesével marha sok kattintással összeszeded a mezőket, na erre nekem jobban bejön a klasszik huzivoni mezőbeállítós cucc.

Na ez igaz. Első összerakásnál és átalakításnál sem mindegy.

Természetesen előfordult, hogy node type full content oldala panels-szel készült, mivel három különböző arca volt a node-nak, más kellett a tulajnak, más egy bejelentkezett felhasználónak, és anonymnak.

Hát igen, valóban, ilyen szempontok is vannak, és egyre inkább úgy látom, hogy igazából a Display Suite és Panels egyáltalán nem zárják ki, sőt, inkább kiegészítik egymást.
Mondjuk mindkettő faszán tudja zabálni az erőforrásokat, nem is annyira meglepő módon, az ilyen szintű komplexitás ezzel jár.

Ami nekem nagyon bejövős, az az, hogy a Display Suite-tal rohadt egyszerűen lehet a mezőket definiálni teljesen custom módon, ahogy korábban már beszéltük is egy másik topicban, így:
http://drupal.hu/forum/egy-field-%C3%A9rt%C3%A9k%C3%A9b%C5%91l-egy-m%C3%...
Viszont a beépített Drupal Field API-val erre normális módszert, theme-es gányolások nélkül még nem találtam (azért ez sem lenne rossz) - mármint hogy konkrétan hol kell hozzáadni, melyik alterben, stb...anélkül, hogy definiálnék egy rendes fieldet, amit aztán minden content type-hoz, minden bundle-höz hozzá lehetne rendelni.

Bár megdöbbentően undormány kódrészleteket lehet látni Display Suite-ban is, például a hook_ds_field_info-ban a ui_limit kulcsnál:

  1. 'ui_limit' => array('article|full', '*|search_index'),

hát ez a pipe-os módszer valami elképesztően undorítóan gány, nem is értem, miért szeretik ezt alkalmazni. Én az ilyenektől kivagyok, amikor egy modulban pont alapvetően kerülendő módszereket erőltetnek. Mint a Field groupnál ez a pipe-os bénázás a csoportok és mezők összekapcsolására az adatbázisban is (!!), hát attól is hánynom kell...
No, de eltértem a tárgytól.

A performance miatt no para, egy entitycache, és kb teljesen semlegesítve van.

Az Entity cache-t pont a napokban akartam belőni, olvastam róla ezt a Lullabot Monday-cikket, hogy mennyire brutálisan sokat számíthat adott esetben:
http://www.lullabot.com/blog/article/module-monday-entity-cache
Be is állítom az egyik oldalhoz, amit készítek.
Arra viszont kíváncsi lennék, mi a pálya, amikor elmentem a node-okat, frissíti-e egyből a cache-t hook_node_update-re, stb.
Nagyon kíváncsi vagyok, a DS+Panels kombóval az oldalbetöltések milyen mértékben javulnak az Entity cache hatására :)

0
0