duc-sai képe

A Node Gallery modulnak viszont csak D6-os verziója létezik.

0
0
Sk8erPeter képe

Árggh, bocsánat, igazad van, nem tudom, menetközben miért felejtettem el, hogy D7-hez kellene.
Itt van egy diskurzus a 7-eshez szépen lassan készülő változatról:
Node Gallery: Drupal 7.x version

Mindenesetre nyomtam saját előző hozzászólásomra egy -1-et a biztonság kedvéért, ha már hülyeségeket beszéltem. :D

0
0
SIR VAMI képe

Oké, akk vagy megvárom mire kész lesz vagy keresek egy másikat

0
0
szt képe

Egyébként én se gondoltam, hogy erre jó lesz, de jó lett ;)
Nem is tudom, hogy ez nem egy bug-e inkább...

0
0
pp képe

Nálam úgy néz ki a dolog, hogy van a munka könyvtár, abban a projektek és egy .htaccess amiben ott figyel a RewriteBase, így nem kell beállítani mindenhova. (persze linuxon, mert mekken még egy mysql-t se sikerült fordítanom, nemhogy egy named-nek nekiálltam volna. :)

pp

0
0
Sk8erPeter képe

Addig is figyelmedbe ajánlom aboros korábbi hsz.-ét:
http://drupal.hu/comment/54008#comment-54008
Kicsit így melósabb, de ez is megoldás.

A Media modullal még nincs komolyabb tapasztalatom:
http://drupal.hu/comment/53978#comment-53978

0
0
pp képe

A kérdésed még mindig messze van a konkréttól. :)

Ha egy fieldről beszélünk három dologról beszélünk:

1. Adatbázis reprezentáció

Ez egy vagy több mező a field adatait tároló táblában. Ebben a táblában ezek mellett a filedek mellett még számos információ tárolódik, amivel nem kell foglalkoznod, lévén a FieldAPI-t használod.

2. Beviteli elem (Widget)

Ez a beviteli űrlapon megjelenő formelem(jelen esetben egy olyan select ami multiple). Ezt egy jóízű form alterrel tolja bele a FieldAPI.

3. Megjelenítés (Formatter)

Hogyan jelenjen meg amikor a felhasználó nézi az adott elemet.

Miért nehéz a kérdésed?

Alapesetben, azt az esetet, amikor az elemből több van a Field API úgy kezeli, hogy egy táblázatba beletossz annyi, widgettet, amennyi szükséges. (ha végtelen, akkor ajaxxal bővíthető vezérlőt rak oda).

Természetesen ez felülírható. Pl. ha 1 elem van akkor egy sima select, ha több akkor egy multiple select form elem kerül bele az űrlapba. Lásd a core options widgetet.

Nem tudom, hogy Te mit szeretnél, mert ugye azt is akarhatod, hogy mindig multiple select legyen, és ha a field multiple, akkor a FieldAPI jelenítsen meg neked több multiple select form elemet. Ekkor nem kell csinálnod semmit se.

Ekkor még csak arról beszéltünk, hogy a field multiple. Ha a widget multiple akkor meg kell oldanod azt, hogy hogyan tárolja azt az adatbázisban, tehát egy widget -> db field átalakítást kell végezened a megfelelő hook segítségével.

Érdemes megnézned a examples modul, field_example modulját, ami egy több részből álló widget értékét tolja bele egy adatbázis mezőbe.

pp

0
0
veezee képe

Én is az field_example modulját értelmez(ge)tem.

Az én gondom valójában az általad írt utolsó bekezdés:

"Ekkor még csak arról beszéltünk, hogy a field multiple. Ha a widget multiple akkor meg kell oldanod azt, hogy hogyan tárolja azt az adatbázisban, tehát egy widget -> db field átalakítást kell végezened a megfelelő hook segítségével."

Végül is (mivel a fejemben a field multiple, és a select multiple sokáig kavargott valami homályos ködbe) ezzel szenvedek,azaz, hogy tudom letárolni az adatbázis megfelelő tábláiba a selectek többszörös értékeit.

Mondjuk az is kérdéses, ha a widgeten belül több multiple select is van, akkor ezt inkább érdemes lenne külön-külön táblákba tárolni.

Itt pedig elérkeztem a kezdeti tervemhez, miszerint egy adott tartalomtipus mezői függő-dependens kapcsolatban állnak egymással. (Hasonlót csinál a Conditional fields modul is, azonban az azért nem jó mégsem, mivel már létező táblákat használ, nekem meg ajaxos callback kellene.)Nos a dependens mező-mező kapcsolathoz aztán lövésem sem volt, hogy kezdjek hozzá.Ekkor csináltam meg egy modulba mindezt a hook_alter_form használatával, ami jól működik, de a views nem látja. Ezért szeretném a hook_field-et, hogy a továbbiakban a kimenet kompatibilis legyen a views-el.

Mindezeken túl már az is fellélegzés, hogy számomra is érthetően megfoglmaztad azt, amit én bizony nem tudtam. Ha nem terhes, légyszives a db field átalakítás értelmezésében segíts nekem.

Amúgy nagyon köszönöm a segítséget.

PS.: Bevallom, nekem nagyon nehéz átállni a drupalra.Valóban olyan mint a legó - ha jól emlékszem a Te egyik előadásodon hallottam - , és néha teljesen kiborít a "rücskös teteje".
A Drupal teljesen más gondolkodást igényel mint egy programnyelv. Ráadásul a szakirodalomban rengeteg dolog benne sincs, vagy legalábbis én nem találom.

Köszönöm mégegyszer.

0
0
zeniten képe

A dokumentáció volt némileg hiányos: jó nyomon jártam, csak mivel korábban nem vezetett eredményre, nem hoztam létre a View-ba egy kapcsolatot...

Tehát a módszer:
A fentiek után még létre kell hozni az entitás típusú view-ban egy kapcsoltot, az mutat az eredeti tartalomra - ekkor jelennek meg a tartalom mezői a mezőhozzáadásnál.

Így készítettem egy összesítő nézetet a jelentkezőkről, kvázi adatbázisnak - emellett egy új fület kapott az esemény tartalomtípus, ahol a regisztrációkor bekért adathalmazzal szerepelnek az oda jelentkezők. Ez így könnyen és jól kezelhető.

A token-problémát még nem vizsgáltam azóta, ez volt a fontosabb

F.A.

Ui: egyébként írtam issue-t, és az arra kapott válasz alapján tudtam továbblépni

2
0
KaoszNagymaester képe

Jobban átnéztem, hogy is működik ez a része. A mező típusa "Tartalomra hivatkozás", ebben meg van adva az "Advanced - Nodes that can be referenced (View)" résznél egy view, ami azokat a tartalmakat listázza, amit a felhasználó hozott létre. (Szűrő: Felhasználó: Current Igen)

Ezek után máshogy kérdezem: :)
Meg lehet oldani, hogy ez a szűrő az admin usernél ne működjön?

0
0