Listázásnál nem azt mondjuk meg, hogy mit ne listázzon a lekérdezés, hanem azt, hogy mit igen.

Vagyis a fentiek pontosítása úgy hangzik, hogy

jelenítsük meg azokat a gyümölcsöket, amelyekre

1. nem hivatkozik kedvenc gyümölcs vagy(!)

2. hivatkozik kedvenc gyümölcs és(!) a hivatkozó kedvenc gyümölcs szerzője nem az aktuális felhasználó.

Az 1. pontban foglalt feltétel megvalósítását írta le Den.

A 2. ponthoz fel kell vennünk még egy kapcsolatot: Tartalom:Szerző és ennek a kapcsolatnak a beállításainál megadjuk, hogy a kapcsolata a hivatkozó kedvenc gyümölcs. (Vagyis azt vizsgáljuk, hogy a hivatkozó kedvenc gyümölcsnek ki a szerzője.)

A views 3-ban már lehet csoportokba rendezni a szűrési feltételeket és a csoportok közti kapcsolatot is meghatározni. Itt erre lesz szükség.

Az első csoportban: típus: gyümölcs, hivatkozik rá kedvenc gyümölcs: nem.
A második csoportban: típus: gyümölcs, hivatkozik rá kedvenc gyümölcs: igen, jelenlegi felhasználó (kapcsolata: szerző): nem.

A két csoport közt a kapcsolat: "vagy" a csoportokon belül (az alapértlmezett) "és".

Ez így már majdnem jó. Egy a probléma. Ha nem csak egy user van, aki kedvenc gyümölcsöt küldhet be, akkor a lista szűkítése nem fog megfelelően működni. Mert ha pl. Béla és Géza is kiválasztja kedvenc gyümölcsnek az Almát, akkor mindkettejüknek látszani fog a következő beküldésénél is az Alma a listában. Ugyanis 2. feltétellel csak azt zártuk ki, hogy az aktuális felhasználó által hivatkozott gyümölcs ne jelenjen meg. De ha más is hivatkozott a gyümölcsre, akkor megjelenik, mert azt nem zártuk ki.

Tehát a 2. feltételnek így néz ki pontosan: hivatkozik 1 vagy több kedvenc gyümölcs és(!) a hivatkozások közül egyiknek sem a szerzője az aktuális felhasználó.

No ezt nem tudom hogy lehet megoldani…

Nem egyszerű html kódot kell szerkeszteni, mivel több referált tartalom is kerülhet a végső tartalomba.

Így vagy az embed lehetőséggel a body mezőbe ágyazom ezeket be, vagy paragrafussal oldom meg.

Ami pozitívnak tűnik, hogy a paragrafusos megoldásnál fixen lekorlátozhatók a bevihető tartalmak. Könnyen összelegózható a szerkesztő számára a tartalom és a különálló, valamint referencia mezők helyzete is egyszerűen mozgatható.

Sajnos a drupal alapból nem teszi lehetővé, hogy a különféle mezőket a szerkesztők szabadon átrendezhessék.

Például a tartalomban egy másik tartalom egyes mezői kerülnek beszúrásra, majd folytatódik a szöveges tartalom, aztán megint egy ilyen beszúrás, stb.

Ezért merült fel a paragrafusok használata és ebből következett, hogy ha már sok szekcióra tagolt a tartalom, akkor akár a szerkesztési rész is tagolható lenne.

Viszont felmerült benne, hogy ebben az esetben ez már a sok külön mező miatt nem lassítaná esetleg be az oldalt?

Jelenleg:

• szöveges blokk.
• referált tartalmi rész.
• második szöveges blokk.
• egy másik referált tartalmi rész.
• egy harmadik referált tartalmi rész
• harmadik szöveges blokk
• egy kapcsolt nézet
• referált galéria
• negyedik szöveges blokk
• fix mezők a tartalom végén

Mivel eleve ilyen tördelt a tartalom itt jött az ötlet, hogy akár a szöveges blokkon belüli elemeket is tovább lehetne tördelni. Címsorok, képek, táblázatok, felsorolások részegységekre.

Ekkor a sok külön mező miatt viszont aggódom, hogy lassulni fog az oldal, valamint több helyet is elfoglal az adatbázisban.

A tartalom nem fixen tördelt az, hogy hány szöveges blokk van és hány referált tartalomrész és ezek hogy helyezkednek el mindig az adott cikktől függ.