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
tzotyu képe

Bocsánat, nm tudom miért jelent meg ugyan ez a hozzászólásom kétszer!

0
0
magveto képe

Hát igen, sejtettem, erre rájöttem. :) A másik oldalon azért nem jelentek meg a képek mert a admin/content/aggregator/settings oldalon az "Engedélyezett HTML elemek"-nél nem volt engedélyezve az img... De hogy teljesen úgy nézzen ki, mint az alap oldalon természetesen a "div"-et is be kellett tennem. :)

0
0
magveto képe

Ha jól gondolom kétféleképpen közelíthetek a problémához:

1) Valahogy hozzáadni a lehetőséget, hogy a nézetben, a mezőknél lehessen bejelölni, hogy a képet is mutassa.

2) Ami jelenleg megvan a nézetben is: "Hírolvasó: Törzs"-et úgy szerkeszteni, hogy a szöveget ne mutassa csak a képet.

Ha valakinek lenne ötlete nagy THX

0
0