Képmező végtelen számossággal: az egyik kép megjelölése checkbox-szal "borítóképnek"

Sk8erPeter képe

Sziasztok!

Van 3 képmezőm, végtelen számossággal: ez 3 különböző "galéria". Amikor megjelenítem a node-ot, akkor korlátozom Display Suite-on belül a megjelenítését úgy, hogy csak 1 kép jelenjen meg, így mind a 3 külön mezőnél van egy-egy "borítókép", amire rá lehet klattyogni, ez elvisz egy külön Views-oldalra, ami mutatja galériaszerűen az adott mezőben lévő képeket, stb...
Ez tök jó, de a gond az vele, hogy az 1 képre való korlátozás során mindig csak az első fotót mutatja a sorrendben borítónak.

Én viszont azt szeretném, hogy egy adott képet a mezőn belül egy checkboxos vagy radio buttonös megoldással meg lehessen jelölni borítóképnek, anélkül, hogy meg kéne változtatnom a sorrendet (eddig ugye mindig az első kép a sorrendben volt a borítókép), és azt mutatnám borítóképként, amelyik meg lett jelölve.

Itt leírtam képekkel is illusztrálva ugyanezt, de hátha nektek előbb támad konkrét ötletetek:
http://drupal.stackexchange.com/questions/83524/image-field-unlimited-ma...

Van ilyenre valami kész modul? Vagy kódolni kell? Megoldható anélkül, hogy konvertálnom kellene a megoldást valami másikra, Media Gallery, Node Gallery és hasonlókra?

Köszi!

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
pp képe

kódolós.

Mivel a kép fieldnek nincs ilyen tulajdonsága, ezért szerintem kódolni kell a dolgot.

Itt ugye arról van szó, hogy ds a sorrend tulajdonságot használja arra, hogy megmond melyik legyen a borítókép, ezzel vágva át a fenti gordiuszi csomót.

Talán a legegyszerűbb - ha nem is a legelegánsabb - megoldás, ha felveszel egy külön borítókép fieldet, ahova a borítóképet újra fel kell töltenie a júzernek. Persze itt már használhatsz mondjuk egy filefieldpath modult, hogy ne kelljen feltöltenie, hanem csak "kiválasztania" a képet. Ez a fapad, erre aztán rakhatsz egy kis js-t, ami elrejti ezt a mezőt, hozzáad minden képfield sorhoz valami kis interakciót, amivel ki lehet választani, hogy melyik legyen a kép borító, és ha ezt választja a júzer akkor ennek az url-jét beírod az elrejtett mezőbe.

pp

2
0
Sk8erPeter képe

Köszi a választ!

Mivel a kép fieldnek nincs ilyen tulajdonsága, ezért szerintem kódolni kell a dolgot.

No de hogyan, mi lenne a legmegfelelőbb módja? Itt még nem volt időm reagálni, de írja egy srác a Field Attach API használatát, ezt még nem igazán ismerem.
Ebben van tapasztalatotok? Nekem még át kell néznem, ez hogyan is működik, hogyan tudnám jelen esetben alkalmazni.
Nem gond a kódolás, csak egyelőre a legjobb módszert keresem rá.

Talán a legegyszerűbb - ha nem is a legelegánsabb - megoldás, ha felveszel egy külön borítókép fieldet, ahova a borítóképet újra fel kell töltenie a júzernek. Persze itt már használhatsz mondjuk egy filefieldpath modult, hogy ne kelljen feltöltenie, hanem csak "kiválasztania" a képet. Ez a fapad, erre aztán rakhatsz egy kis js-t, ami elrejti ezt a mezőt, hozzáad minden képfield sorhoz valami kis interakciót, amivel ki lehet választani, hogy melyik legyen a kép borító, és ha ezt választja a júzer akkor ennek az url-jét beírod az elrejtett mezőbe.

Na várj, a filefield_paths modul elvileg a replacement patternekre alapul, nem? Ennek kiváltására én inkább a szantog által fejlesztett, más megközelítésű, entitás-alapú File Entity Paths modult használom (mondjuk tény, előbbit aktívabban fejlesztik :P). Na de ez sztem nem kapcsolódik a problémához.

Nem az Entity API+File entity (fieldable files)+Media modul kombóra gondoltál? Mert tudtommal így válik lehetővé a különböző, immár korábban feltöltött fájlentitások kiválasztása, duplikáció nélkül.

Így a trükközéssel már nem hangzik rosszul, az ötlet mindenképp ügyes, bár nekem elsőre kicsit nyakatekertnek tűnik, van vajon szebb, talán egyszerűbb megoldás ennél az API-k használatával? Például a Field Attach API megfelelő lehet? Ismeritek?

Egyébként felmerült bennem még a Flag modul használata is, de tudtommal azt egy adott mező különböző elemeinek megjelölésére nem lehet felhasználni - habár az is igaz, hogy ezek az elemek már külön csatolt fájlentitások a fentebb említett modulok miatt, így akár elképzelhető lenne az azzal való megjelölés is, nem? De ez lehet, hogy tévút.

0
0
pp képe

FileField Sources amire gondoltam, csak miközben írtam továbbgondoltam, hogy az igazi egy IMCE-s browser lenne, de akkor a legkönnyebben úgy lehet megtalálni, ha a filefield_path-al a megfelelő helyre összegyűjtjük az egy node-hoz tartozó fájlokat.

Lehet, hogy a javasolt megoldásom nyakatekertnek tűnik, de én abból indultam ki, hogy nem azt kell tárolni minden egyes fájlhoz, hogy az borítókép-e avagy sem (hisz nem lehet egyszerre két borítókép), hanem a fájloktól függetlenül azt kell letárolni, hogy melyik fájl a borítókép.

A megoldás elég gyökér júzer interfész, hisz a fájloktól függetlenül kell megadni egy fájlt, ami ráadásul más is lehet, mint ami a galériában van. Ezért javasoltam második lépésben a júzer interfész csiszolását.

Ha a júzer interfész felől indulunk el, akkor a szabozee által javasolt megoldás tökéletes, de ott az adattárolás és tartalmak betöltése lesz egy picit bonyolultabb, amit elfed előlünk a rendszer.

pp

0
0
Sk8erPeter képe

az igazi egy IMCE-s browser lenne, de akkor a legkönnyebben úgy lehet megtalálni, ha a filefield_path-al a megfelelő helyre összegyűjtjük az egy node-hoz tartozó fájlokat.

Uhh, hát ez őszintén szólva számomra pont nem tűnik egy túl időtálló és elegáns megoldásnak: ez ezek szerint azt jelentené, hogy egyrészt könyvtárfüggő a megoldásom, másrészt lényegében elérési útvonalhoz kötöm azt a tulajdonságot, hogy melyik kép lesz a borítókép a sokból. Tehát mondjuk adatbázis szintjén egy mezőnév-elérési út kapcsolat lenne, az meg igen csúf és rugalmatlan megoldás, akkor már file id szerint kellene nyilvántartani a kiválasztott képet. Ha pedig utóbbit szeretném a javasolt könyvtárkigyűjtős, IMCE-jellegű megoldás esetén, akkor a fájlokat nyilvántartó táblából kellene kikotornom kiválasztáskor, hogy melyik file id-hoz is tartozik a kiválasztott kép elérési útja, így kapnám vissza a file id-t, amit aztán a kapcsolótáblába le tudnék menteni. Na de akkor már eleve nem könyvtár szerint kellene kigyűjtenem az adott mezőhöz tartozó képet (mi van, ha véletlenül valami hülye okból ugyanebbe a könyvtárba kerül egy nem feltétlenül oda kapcsolódó kép? akkor a felhasználó azt máris ki tudja választani), hanem file id, file entity alapján, ami egy ennél jóval erősebb, megbízhatóbb kapcsolat: például a file id nem változik túl sűrűn, de a fájl elérési útja, neve akármikor változhat, és akkor az ilyen jellegű változásokra is fel kellene készíteni a modulomat: máris nem tűnik olyan egyszerűnek ez a megoldás, sőt.

Lehet, hogy a javasolt megoldásom nyakatekertnek tűnik, de én abból indultam ki, hogy nem azt kell tárolni minden egyes fájlhoz, hogy az borítókép-e avagy sem (hisz nem lehet egyszerre két borítókép), hanem a fájloktól függetlenül azt kell letárolni, hogy melyik fájl a borítókép.

Jaja, de végül is ez megoldható lenne akár modul által definiált táblával is (Schema API), és lenne egy kapcsolótáblám mondjuk mezőnként, és abban letárolnám, melyik file id a borítókép, aztán minden űrlapmegjelenítéskor ezt csekkolom, és mondjuk a radio buttont ahhoz a képhez rakom, amelyik ki lett választva, a többinél üres a radio button.
Csak kényelmesebb lett volna ezt megoldani valami kész megoldással. :(
Főleg, hogy akkor a megjelenítést is meg kell oldani, hogy node megtekintésekor hogyan mutassam a cover photo-t, stb.

A megoldás elég gyökér júzer interfész, hisz a fájloktól függetlenül kell megadni egy fájlt, ami ráadásul más is lehet, mint ami a galériában van.

Na ja, ezeket mindenképp el akarom kerülni.

Ha a júzer interfész felől indulunk el, akkor a szabozee által javasolt megoldás tökéletes, de ott az adattárolás és tartalmak betöltése lesz egy picit bonyolultabb, amit elfed előlünk a rendszer.

Na viszont erre még nem kaptam magyarázatot szabozee-től, hogy értette, mert számomra nem igazán világos. Attól még, mert van egy Field Collectionnel létrehozott külön mezőgyűjtemény-entitásom, és így tartozik egybe a képmező, meg esetleg egy radio button, hogy lesz a kettő összekapcsolva? Mitől lesz ez így egyszerűbb, hogyan kerülném már el ezzel a kódolást? Na meg az sem mindegy, hogy így a Field Collectionnel létrehozott entitásban lévő mezőbe kellene MIGRÁLNOM az összes jelenleg meglévő képet, a meglévő mezőkből... nemde?

0
0
szabozee képe

https://drupal.org/project/field_collection

Ha a korlátlan számú kép mező mellé korlátlan számú checkbox-ot ( vagy egyéb mezőt ) rendelünk, akkor szerintem így a képek közül megjelölhetőek azok, amelyek használni szeretnénk borítóképnek.

0
0

szabozee (zee zee zee kukac free mail pont hu)

nevergone képe

Nem biztos, hogy csak ezért megéri a Field Collectiont bevetni. Én azt tapasztaltam, hogy elég jól le tudja rontani az oldal teljesítményét. Mindig érdemes mérlegelni egy feladat megoldásainál, nehogy „ágyúval a verébre” hatás, vagy „túlfejlesztés” lépjen fel.
Kapcsolódó írás: http://szantogabor.com/hirek/hogyan-erdemes-valasztani-egy-feladat-lehet...

2
0
Sk8erPeter képe

jó ez a cikk :D
Kicsit elgondolkodtatott rajta, hogy bizonyos content type-oknál talán túlerőltettem a taxonómia+term reference mező használatát. Mondjuk ez egy külön témát érdemelne, de jó ilyeneket olvasni :)

0
0
Sk8erPeter képe

Köszi az ötletet, na de hogyan lesz a Field Collectionnel vagy akár anélkül egyáltalán "összekapcsolva" a checkbox és az Image field? Hogyan kreálódik mindig pontosan ugyanannyi checkbox, mint ahány kép is feltöltésre kerül? Mitől fogom tudni, hogy az 5-ös checkbox pont az 5-ös képhez kapcsolódik? Hogyan néz ki ez modulfejlesztés szintjén?
Na meg bennem felmerül az a kérdés is, hogy ehhez miért kellene feltétlenül a Field Collection modul, miért ne lehetne akár pont ugyanazzal a kóddal megoldható adott tartalomtípuson/taxonómiakifejezésen belül (kiegészíteném a field_image_pelda_blabla mezőt mondjuk field_image_peldablabla_checkbox-szal)? Legalábbis elsőre nekem nem világos, hogy értetted, bocsi, ezt ki tudnád fejteni bővebben?

0
0
balagan képe

A field collection-nel nekem is meggyűlt a bajom, valami érdekes hibát is generált, mert mint kiderült, ha jól emlékszem az Entity Reference-szel akadt. Volt valami 2 éves issue, aminek a patch-e már nem ment be valamikor, és úgy látszik nem is erőltették később. Emellett az adatbázis-lekérdezést is bonyolította +2 joinnal, így az ötödik joinnál fel is adtam :)

0
0