persze egyátalán nem vagyok benne biztos, hogy ez így működni fog.

pakoljunk bele még flag meg rules modult, hamár lúd legyen kövér. a gyümölcs tartalom típusban legyen egy flag, "felhasználta". ezt egy nem-globál flag és egyik csoport se használhatja. :) itt van a kétségem, hogy ettől még a következő lépés működni fog e.

legyen egy rule, ami tartalom mentésekor, ha a tartalom típusa kedvenc gyümölcs, akkor a szerző nevében ráteszi a hivatkozott gyümölcs nodera a "felhasználta" flaget. (nem tudom eldönteni hirtelen, hogy ez itt eltörik e amiatt, hogy a flag beállításaiban az van, egyik csoport sem használhatja, de az meg szükséges, hogy kézzel ne tudja birizgálni ezt a flaget. ha elrejtem csak, az nem elég, mert gyalog hívhatja a flag urlt és akkor kijátssza a szisztémát. ezt is meg lehetne kerülni de akkor már tényleg rémálom bonyolult lesz a kerülőút)

innen már gyerekjáték, a view ami a node reference mezőt eteti, azokat a gyümölcs tartalmakat mutatja, amiket az aktuális user nem jelölt még meg a "felhasználta" flaggel.

a flag leszedését meg szintén egy rule intézi, ha esetleg törölnénk a kedvenc gyümölcs típust, akkor újra felszabaduljon az a usernek.

vagy x terv, aka special tactics, írunk egy modult, vagyhát vki ír.. :D

Ezzel a hozzáállással az a probléma, hogy vannak olyan beállítások és megoldások amiket pénztárcával nem lehet bírni.

Nekem egyszer sikerült egy olyan megoldást összekattintanom ami bármilyen nagy szervert leültet. (bármilyet, mivel önmagát dosolta)

Szakértettem olyan oldalt, ahol 1 oldalletöltésből csináltak 30-at különböző AJAXos megoldásokkal.

De ezek csak tipikusan hibás megoldásai egy egyszerű feladatnak. Vannak azonban olyan feladatok amikhez nem lehet gyors megoldást gyártani. Képtelenség. Ilyenkor a feladatot részfeladatokra kell bontani, amik már megoldhatóak rövidebb idő alatt. És itt az időt ne úgy képzeld el, hogy 2 perc, hanem az adott feladatba tartozó elemek számával arányos képletre gondolj. És ez a képlet nem mindig úgy néz ki, hogy mondjuk 2*N (ahol N az elemszám, mondjuk a node-oké), tehát ha kétszer annyi node-od van akkor kétszer annyi teljesítmény kell. Simán lehet valamilyen exponenciális összefüggés, mondjuk kettő az N-ediken.

http://www.cs.elte.hu/~kiraly/alg.pdf

Amiért biztosan hibás a „veszek még vasat” megoldás, mert nem létezik univerzális megoldás. Nincsen. Csak probléma van és megoldás, így együtt. Egy megoldás ami egyik problémára gyógyír lehet a másik problémádat épp elmélyíti. (pl. a veszek még vasat biztos károsan hat a pénztárcádra)

pp

Igazad van, végül is elmentődik minden adatbázisba, nem csak a kódból kotorja ki a modullal definiált content type-okat sem. Kérdés, vajon ez tényleg hatékony-e így. (Mindent jól benyomni serializálva adatbázisba, aztán unserializálni, jó kis memóriazabáló módon...)

Én úgy gondolom, hogy a node_type_save() elment egy tartalomtípust, mint pl. amikor modulból létrehozunk egy tartalmat vagy bármit. A hook_node_info() pedig definiál egy olyant, ami a modul működéséhez feltétlenül szükséges.

Ja, hát én arra gondoltam - bár lehet, hogy nem sikerült jól kifejezni magam az eredeti hsz.-ben, aztán még beleírtam egy téveset is jól összecsapva -, hogy a node_type_save-vel mentett cuccok például az admin-felületen létrehozott content type-ok, tehát amiket én összeklattyogtatok a GUI-n, VAGY olyanok, amiket mondjuk modulból, "programmatically" hozok létre, a megfelelő paraméterekkel, míg a hook_node_info() meg arra szolgál, hogy egy modullal tudjak én is kínálni egy modul szerinti default tartalomtípust (ahogy írtad, amire feltétlen szükség van), ami aztán végül szintén bekerül az adatbázisba, ahogy írtad is.

Szóval ez még nem a Drupal 8, ezért itt még nincs olyan az alaprendszerben, hogy egy adat „csak úgy jön” valahonnan.

Ezt hogy érted? Mármint az említett dolgok miben lesznek mások D8-ban?