A különböző Views-megjelenítések szerepe?

Sk8erPeter képe

Sziasztok!

Már jóideje használom a Views-t, mégis van pár mai napig homályos terület, például a különböző megjelenítések közötti érdemi különbség, mire jó az egyik, mire jó a másik.

Views 3 - Megjelenítések Views 3 - Displays

Page/Oldal: OK, oldal, van hozzá path, lehet menübe rakni, a többi megjelenítéshez hasonlóan lehet contextual filtert hozzárendelni, különösebben nem kell magyarázni.
Block/Blokk: egy dinamikus blokkot hoz létre, megjelenik a blokkok átrendezőfelületén, ez sem nagyon szorul magyarázatra.
Feed/Hírcsatorna: a magyar fordítás elég jól kifejezi, miről van szó, meg biztos sokan használtak már ilyesmit, szóval ez is viszonylag triviális.

Attachment/Csatolmány Embed/Beágyazás: na, ezeknél már nem nagyon tudom például, melyiket érdemes használni egyik vagy másik esetben, és miért.
Példa: van egy hír, alatta akarok listázni egyéb híreket, contextual filterrel kizárom azt a node id-t, amit épp megjelenítek, és megjelenítem a "többi hír" view-t. Na most ezt embeddel oldottam meg, de elvileg megoldhatnám csatolmánnyal is, nem? Most akkor mi a különbség?

Content pane/Tartalomtábla: ez is magyarázatra szorul. Panels-hez kell? Vagy másra is jó?

Context/Környezet: tudtok mondani értelmes use case-t?

Date browser/Dátumböngésző: gondolom sima dátum szerinti böngészésre lenne használható, de eddig neke nem sikerült működésre bírnom, általában hibába ütköztem, de elég volt nekem a Calendar által biztosított dátum szerinti böngészési lehetőség.

Entity Reference: itt miért is jó?

Pár nagyon rövid példa, vagy néhány szó is elég lenne, csak hogy lássam a fától az erdőt. (nem kell mindre egyszerre, részleteiben is elég, ha épp valamelyikről beugrik valami :) )
Előre is köszi!

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

Entity reference: ez entity reference típusú mezők settings oldalán van egy olyan, Entity selection mode - Views: Filter by an entity reference view. Na ehhez a beállításhoz lehet vele nézetet szerkeszteni.

Content pane: Panels-re épülő cucc, hasonló a blokkhoz, viszont nagyságrendekkel tágabb lehetőségekkel. Használhatja a ctools contextjeit pl contextual filterek kezelésére, lehetőséget ad különböző views adatok felülírására panels uin keresztül, pl title, sőt, felfedett szűrőket is lehet hozzá rendelni, mint beállítási lehetőséget, ilyenkor akár inline page editorral klikk klikk lehet paraméterezni a nézetet panenként. (Magyarán ha egy oldalra be akarsz szúrni két nézetet, az egyikben 3, a másikban 6 elemmel, nem kell új nézetet csinálni, hanem a pane hozzáadásakor megadhatod. Még magyarabbul: Mezei user számára lehetőséget biztosít a views használatára az űrhajós views_ui nélkül.)

Context: Ez megint egy ctools vudu. A panels és társai contextekbők, illetve azok adataiból dolgoznak. Egy context lehet egy node, user, vagy bármi, na ilyen contexthez készíthetünk adatokat elő vele, amit pl egy content pane típusú nézet contextual filtere használhat fel forrásként. Hirtelen jobb példa nem jut eszembe, de lehet vele ilyen elcseszett jogosultságkezelést csinálni, hogy van egy user flaged, összevissza flagelgetsz usereket, csinálsz egy ilyen context típusú nézetet, amiben összegyűjtöd a flaggelt userek uidit, és felraksz egy content panet, amiben az van, hogy 'helló fleggeltuserek!', és akkor be tudod állítani, hogy csak a flaggelt userek lássák.

Attachment: Ezzel az egyik alnézethez csatolhatod ezt a nézetet. Én draggable_viewsal használom zömében, ha van egy lista, amit kézzel kell sorrendezni, akkor ahhoz a nézethez, ami a tartalmakat megjeleníti, hozzáadok egy csatolmány nézetet, ami a draggable tablet tartalmazza, és persze csak az adminok látják. De attachmentet használ pl a gyári glossary nézet, abba is érdemes belenézni, ott konkrétan a bötűket csapja a view tetejére.

Embed: Na ebben nem vagyok biztos, 6.x-ben ez olyan volt, amit csak views_embed_viewel lehetett beágyazni, semmi sallang, meg plusz beállítás, csak egy nyers view. Kb mint a preview.

Page: Ismerek olyan céget, ahol az ilyen típusú nézet használatáért ölnek. Mondván, ha page manager van használva, az ő dolga, hogy a pageket managelje, nem a viewsé. Ebben van valami, de nálam azért van bőven olyan features, amit nem akarok panels függővé tenni (főleg admin oldalak). Az viszont tény, hogy 2012-ben a user/%/akarmi típusú view már nem menő.

4
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öszönöm szépen, ez nagyon hasznos volt!! Így már sokkal értelmesebbnek tűnik az egész. Amúgy én őszintén szólva ehhez átfogó leírást angol nyelven sem találtam eddig (lehet, hogy rosszul kerestem), tehát ilyen szempontból a leírásod egyedülálló. :D

"Az viszont tény, hogy 2012-ben a user/%/akarmi típusú view már nem menő."
Itt ezt ki tudod még fejteni?

0
0
eMeLA képe

Átfogó leírást azért nem találsz, mivel a kilenc fajtából legalább 3-at nem a views adja hozzá, hanem más kiegészítő modul...

0
0

...mit tudok: http://web.termuves.hu

Sk8erPeter képe

Ez igaz, de tulajdonképpen ezek a leggyakrabban használt modulok közé tartoznak, végül is nem lenne annyira valóságtól elrugaszkodott, ha egy-két cikket elolvasva már összeállna a kép. De akkor átfogalmazom: soknál külön-külön rákeresve sem találtam értelmes use-case-t példaként leírva.

0
0
szantog képe

Az alap probléma, hogy a views page saját maga kezel minden argumentumot, nem használ menu loadert, vagyis az egyes argumentumok nem menu objectek, tehát nem lehet hozzáférni menu_get_object()-el. A node/10 útvonalon a $node = menu_get_object() visszaadja a nodeot, node/10/views_path útvonalon nem.

Azon kívül ott vannak azok a korlátok, hogy pl argumentum validálásnál csak egy nézet érvényesülhet. Tipikus példéja a taxonomy/term/% útvonalak felülírása, ha csak egy szótárra akarod érvényesíteni a nézetet, akkor lehet ugyan validálni az argumentumot, ellenben kinyírod vele az összes többi szótárat.

Szóval a valami/%elem oldal tákolására page manager való.

2
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

Hmm, ezek jó és érdekes szempontok. Lényegében rávilágít, hogy milyen keveset tudok a Drupalról és moduljairól, amikor azt hittem, hogy már tudok valamit, kiderül, hogy mégsem. :D
A page managert őszintén szólva még elég keveset használtam, de amiket írtál, eléggé megváltoztatják a megközelítésemet, mert én azért még használok /%-os útvonalakat, contextual filterrel kiegészítve, ezek szerint csak le vagyok maradva.

A taxonomy/term/% útvonalak felülírásának problémájával már szembesültem, a Drupal beépítettje eléggé tönkrevágja az alapértelmezett megjelenítést, és amin nagyon csodálkoztam, hogy amikor engedélyeztem ezt a nézetet, a taxonomy-hoz rendelt igen sok fieldem (útközben kellett kiegészíteni a megrendelő kérése szerint, lényegében már kábé át kéne ültetni taxonomy-ról "rendes" content type-ra, annyi fieldet tartalmaz) egyáltalán nem jelent meg. Ez mondjuk kétlem, hogy a normális működés, de azonnal le is tiltottam inkább a Views taxonómia-felülbírálását.

A page managerrel viszont az a gáz, hogy nagyon szar a helpje, konkrétan nincs neki jópár alapvető dologhoz.
Pl. pár fontos link a helpből:
Page manager Ctools
Ahova ezek mutatnak, egyszerűen nem készültek még el: http://drupal.org/node/528046, http://drupal.org/node/528036, http://drupal.org/node/528038, http://drupal.org/node/528040, http://drupal.org/node/528044.
Tök jól lehet belőlük tanulni... :D

A válaszaidat köszi ismét, megint tanultam valamit!

0
0