Sziasztok!
Lehet, hogy nagy blődséget kérdezek.
Olyan CCK mezőt szeretnék létrehozni (vagyis tul. képp. egy olyan név-érték párt), ahol a mező neve is node reference típusú. Olyan ez, mint az adatbázisoknál a kapcsolótábla (itt: egy tartalomtípus), vagyis összekapcsol két másik tartalomtípusba tartozó node-ot (illetve nem is egészen olyan, mert ezekből a név-érték párokból többet is szeretnék egy node-hoz hozzáadni, ugyanakkor mégis olyan, mert olyat is szeretnék, hogy egy egy darab név-érték párt tartalmazó node-ot felhasználok egy újabb kapcsolatban). Ez egyrészt azért jó, mert a "mezőnév"-hez is rendelhető cím, leírás, esetleg kép, másrészt mert így tetszőleges számban rendelhetők név-érték párok egy node-hoz (tudom, hogy CCK-val is, hiszen, ha nem adok értéket egy mezőnek, az meg sem jelenik).
Kezdek belezavarodni, úgyhogy próbálkozom egy példával:
Három tartalomtípusom van: Személy (Jani, Béla, Icuka...), Tulajdonság (Hajszín, Iskolai végzettség, Kedvtelés...) és Tulajdonságérték (ezek egy node reference-szel kapcsolódnak a tulajdonságokhoz. Például a Szőke, a Barna és a Vörös a Hajszínhez).
- A Janiról szóló node-ban lehessen megadni, hogy a haja színe vörös (a "haja színe" és a "vörös" is link). Ekkor van több field_tulajdonsag és field_ertek mezőm, de ezek csak az én számomra jelentenek név-érték párokat!
- Bármilyen új tulajdonság legyen létrehozható, de a tulajdonságot létrehozó szerkesztőnek ne az admin/content/types/ lappal kelljen dolgoznia.
- Vagy lehessen úgy hajszínt rendelni Bélához, hogy létrehozok egy Tulajdonság-Érték tartalomtípust, amiben van egy field_tulajdonsag (node ref) és egy field_érték (szintén node ref), majd egy ebbe a típusba tartozó node-ot, amiben összekapcsolom a Hajszín node-ot a Vörös node-dal és végül ezt a node-ot rendelem Bélához.
Mindez persze kacagva megvalósítható, de természetesen elhasalok a nézeten, amit azért hozok létre, hogy felfedett szűrők használatával lehetővé tegyem a hajszín (és az összes többi tulajdonság) szerinti keresést.
Köszi a türelmet :)
PS
A lényeg lemaradt...
Működik minden a nézetben, csak nem úgy, ahogy szeretném. Maradjunk az utolsó esetnél:
A nézethez tartozó relációval ki tudom listázni azoknak a neveit, akiknél szerepel a "vörös" érték, de a felfedett szűrő ugyebár egy darab select, ami az összes tulajdonság összes értékét tartalmazza. Összesen egy helyett tulajdonságonként szeretnék egy selectet, valahogy így:
Egyik select:
- Címke: Hajszín
- Opciók:Vörös, Szőke, Barna
Másik select:
- Címke: Kedvtelés
- Opciók: Fagyizás, Zenehallgatás, Drupal faragás...
stb. Az eredmény azoknak a listája legyen, akik minden megadott feltételnek megfelelnek.
Gyanítom, hogy ez így nem fog menni, de akkor hogyan szervezzem a tartalmakat? Vagy a lekérdezést saját modulban tudom csak megvalósítani (esetleg a Views API használatával)?
Fox Mulder
Ez nem taxonomia?
Lehet nem értem amit akarsz, de nem lenne egyszerűbb létrehoznod egy Hajszín és Kedvtelés szótárat és abba felvenni a megfelelő kategóriákat? (Vörös, Szőke, Barna stb.)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
nem tudom
Itt bővebben kifejtettem az egész kérdést. Nekem is gyanús, hogy eddig egyáltalán nem volt szükség a taxonómiára.
Fox Mulder
taxonomy vs cck
a taxonomy/kategórizálás leginkább abban különbözik a cck-tól, hogy a taxonomy-val olyan tulajdonságokat adunk a nodehoz ami alapján keresni vagyis osztályozni fogjuk a node-okat. Ez az elkészített adatbázis struktúrában is látszik, hisz a kategóriák táblája indexelve van a cck táblái meg nincsenek. (ezen persze lehet változtatni, de ahhoz bele kell túrni az adatbázisba, tehát máris oda a kattintgatós felület varázsa.)
A cck sokkalta rugalmasabb mint a kategórizáló rendszer hisz a cck-t alapvetően arra találták ki, hogy adat elemeket adjanak az adott node-hoz. Ezeket aztán megjelenítjük az adott node megjelenítésekor. (tehát nem arra lett kitalálva, hogy sok node közül kiválasszunk egy párat)
Ha végtelen számú lehetősége lehet egy mezőnek (pl. címből az utca/házszám/emelet/ajtó) akkor CCK- mezőt érdemes rá felvenni és nem engedni keresni, vagy csak bizonyos korlátok között. Ha véges számú lehetőség van (pl. címből a város) akkor kategória és lehessen rá keresni.
Minden egyéb esetben a kattintgatós módszert el kell felejteni és vagy adatbázis optimalizálni kell, vagy saját modult és megoldást kell fejleszteni.
Mielőtt valaki félreértene egy szabad szavas kereső mező működhet (persz ha megoldják, hogy ne legyen sechole a views-ban) 10-20 elemre tökéletesen de nagyobb, már pár ezres tételnél is rendesen meg tudja fektetni a szervert.
Erre szoktam én azt mondani, hogy műxik, nem tudjuk miért, nem tudjuk hogyan, nem tudjuk meddig de műxik. Aztán amikor tízről felnő az elemek szám százra megy a fejvakarás, hogy na akkor most mennyi szerverbővítés kell ide, holott itt nem az erőforrás a hiba, hanem a hozzáértés és a tervezés hiánya. (mondjuk egy alap indexelés angol nyelven, magyarban meg egy kis szótövező/indexelő ;))
És tessék megkapaszkodni létezik olyan probléma amire a mai ismereteink szerint nem létezik jó megoldás. Ezért működik a nyilvános kulcsú titkosítás, mely titkosítási algoritmusa ismert ezáltal könnyedén feltörhető, csak azt az icipici időt rá kell szánni. (pár száz év megfelelő hosszúságú kulcsnál)
Minél általánosabb egy rendszer annál biztosabb, hogy nem létezik rá jó megoldás. Szóval konkrét feladatnál lehet adni konkrét választ.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu