Node type sminkelésekor a Drupal 5 alatt a következő kóddal ki lehet iratni a CCK mezőt (címke+tartalom):
print $node->content['field_cckfield']['#value'];
Drupal 6 alatt hogy lehet kiiratni a CCK mezőt? , mert ez sajnos nem működik.
Lehetőleg ne csak egy értéket mint ezzel : print $node->field_cckfield[0]['value'];
Drupal verzió:
Fórum:
drupal_render
belenéztem a cck modulfileba (content.module) és ott találtam egy "implementation of hook_field()" részt, ami eléggé el is magyarázza, hogy mit csinál. a magyarázatban ezt írja:
tehát ezek alapján egy 'cckfield' nevű mezőt így tudsz megjeleníteni:
print drupal_render($node->field_cckfield);egyébként nemrég hallottam (a drupalconon), hogy ezt a módszert (a .tpl.php -kban a $content kiíratását elhagyjuk és magunk állítjuk össze a dolgokat így, hogy print $node->field_valami[0]['value'] stb.. ) szóval, hogy ezt úgy hívják template butchering és nem igazán okos megoldás a 6.x drupalban. helyette a theme_preprocess_node -ot kell inkább a template.php -ban megvalósítani és ott kedvünkre módosítani a $content (és egyéb változók) tartalmát. az előadó szerint az esetek igenkicsi százalékában van szükség az alapértelmezett (node modullal gyárilag érkező) node.tpl.php piszkálására.
ugyanitt emelték ki (bár ez most fél-off), hogy a cck mezőknek írhatunk (egy saját modulban) egyedi 'formatter' -eket is, amiket aztán az admin felületről tudunk kiválasztani. (mint ahogy mondjuk a lightbox az imagefield típusú mezőkhöz felajánl saját formattert)
érdekes elgondolás, próbálom átszoktatni magam, vannak előnyei na. :)
http://szeged2008.drupalcon.org/program/sessions/node-templating
-
clear: both;
template butchering
miert nincs errol tobb info?
http://www.google.com/search?q=%22template+butchering%22&hl=en&start=0&s...
ezt a szokapcsolatot Te talaltad ki :) amit a google nem ismer az nem letezik..
de egyetertek, szeretnem en is betartani. de neha amikor annyi cucc van egy valtozoban es nekem csak egyet kell megjeleniteni akkor nehez a jo utat valasztani a konyebb helyett..
nem én talátam ki :)
szegeden volt egy node templating előadás, egy lány tartotta. tőle hallottam ezt, az előadás közben hangzott el. nagyon megtetszett, találónak tartom. azzal kezdeni, hogy kütöm a node.tpl.php -ból a print $content részt, az nem sminkelés, azzal csak lefejezed szerencsétlen .tpl -t. később minden új mező hozzáadásánál vagy bármilyen módosításnál kódolnod kell majd... stb stb.. könnyű belátni, hogy nem célravezető módszer ez. (de nyilván te is tudod ezt, írod is hogy egyetértesz:)
(ugyan ez a lány mondta egyébként azt is, hogy display:none is for loosers:)
-
clear: both;
sminkben adatot módosítani?
Sminkben adatot módosítani gányolás. (Persze én is csinálom, meg még ennél durvább dolgokat is. :D) Sminkben legfeljebb megjelenítést, "statikus" elemeket illik módosítani. Például így jön ki a motorból:
És helyette ezt szeretném:
... ahol a "valami" mondjuk nyelvfüggő, vagy az adat értékétől függően változik. Viszonylag ritka eset.
A nagykönyvet szépen megtanulta a leányzó, de nem sok valós munkatapasztalata lehet. :) Például a keresődoboz labeljét rendszeresen display:none-nal tüntetem el. Egy ilyen dolog miatt többnyire nem éri meg formalterezni, hacsak nincs napi egymillió látogatónk, ahol az a pár byte is számít. Általában kissé egészségtelen dolog, ha a megjelenítési célból írt PHP kód önmagában egy nagyobb modul méretére duzzad – mert itt nem élvezzük a közösségi karbantartás előnyeit.
több dologgal se értek egyet :)
az előfeldolgozó azért van, az a célja és értelme, hogy a számára elérhető változókat módosítsam benne még mielőtt azok a sablonba kerülnének. _semmi_ gányolás nincs benne, ez a rendeltetésszerű használata.
tipikusan ilyen feladat, hogy a node valamilyen paraméterétől függően szeretném változtatni mondjuk a $content változó tartalmát, ami ugye más, a nodeban egyébként is szereplő változókból áll össze gyárilag is. (gyárilag is preprocessor állítja össze). nem feltétlenül csak más szemantikát akarok adni neki, ezer példa van, amit pikk-pakk el lehet úgy intézni egy előfeldolgozóban, hogy közben az admin felület funkciói nem sérülnek, nem töröd el a sminkrendszert, csak módosítod a kimenetet. erre való.
ez persze nem azt jelenti, hogy mondjuk előfeldolgozóban db_query -t futtatok, bár elvi akadályát ennek se látom.
a display:none -al meg az a helyzet, hogy lehet használni helyenként, az viszont lúzer, amikor mondjuk úgy "sminkelek", hogy bevett gyakorlat, hogy ha valamit el akarok tüntetni, rádobok egy display:none -t aztán jóvan. na, _ez_ looser.
a keresés űrlap módosításához egyébként nem kell saját form_alter modul, mert ugye van neki saját előfeldolgozója :) ami _pont arra való_ hogy például kivegyed az űrlapból a labelt, vagy képre változtasd a submit gombot vagy hozzátegyél még amit akarsz.
persze minden tiszteletem a tiéd, én azt írom, ami szerintem. :)
-
clear: both;
szubjektív
Erről azt hiszem egyszer volt itt egy beszélgetés, hogy hol ér véget az adat és hol kezdődik a megjelenítés. Én ebben elvileg elég konzervatív vagyok, és azt mondom, attól, hogy lehet mindenfélét csinálni a sminkben, attól még nem ott kell (hanem pl. hook_nodeapi()-ban). A smink feladata a megjelenítés. Itt szerintem legfeljebb arról lehet vita, hogy valami adatprobléma, vagy megjelenítési probléma – és itt van egy szürke zóna, ahol a megítélés elég szubjektív.
Hopp, na erről a kis aranyosról mindig megfeledkezem. Köszönöm, hogy emlékeztettél. :)
mondok egy példát
igazán nem akarok vitatkozni.. :)
például addott tartalom típusom egy bizonyos mezőjét teaser nézetben szeretném a body előtt látni, full nodeban pedig mögötte. minek pakoljam ezt egy modulba, mikor _pont erre van_ az előfeldolgozó, hogy megszerkessze a $content tartalmát? :)
tényleg hozzáállás kérdése amúgy, szóval tényleg nem vitatkozok tovább ezen. mindenesetre valami oka van, hogy bevezették az előfeldolgozókat, nyilván nem tették volna, ha hook_nodeapi igazából a helyes megoldás. :)
-
clear: both;
ez egyértelműen smink
Az, hogy a mező a body előtt vagy utána van, az szerintem egyértelműen megjelenítési kérdés, tehát valóban a sminkben a helye. De a mező értékét már nem ott manipuláljuk (elvben, persze én is szoktam vizet prédikálni és bort inni).
Baromi izgi téma ;)
http://palocz.hu/node/200
Ha egy kicsit belenéztek akkor az utolsó megoldás pont ezt tudja. Persze itt most a gombot módosítom és nem a feliratot tüntetem el de az elv pont ez.
Még hozzá is szóltatok, de a "nehasználjálimagegombot" felkiáltás fátyolán át nem vettétek észre a lényeget. Sajnos ügyfél pont ezt kérdezte ezért van benne az kép gomb amivel én se értek egyet. Most a tanfolyamon már a feliratot tüntettük el így.
Az meg egy baromi izgalmas kérdés, hogy node.tpl.php vagy preprocess vagy a contemplate modul legyen a színtere a formázásnak. ;)
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
izgalmas
Észrevettem, csak mindig elfelejtem, hogy használni kellene :) Az érdekfeszítő vita pedig nem a formázás színteréről szól, hanem arról, hogy egyáltalán hol kezdődik a formázás. Na így már mindjárt más, nem? :)
Közben a kérdezőnek nem nagyon adtunk kézzelfogható választ:
$node->field_mezoneve[0]['view']-val érdemes próbálkozni, általában pedig tedd fel a Contemplate modult, az megmutatja az elérhető változókat, onnan könnyen lehet puskázni tpl.php-k írásakor.
ez mar megint megvaltozott?
/help/content/theme-node-templates szerint a
$<FIELD_NAME>_renderedvaltozo tartalmazza a renderelt CCK mezot..ezt a sok sugot egyszer mar el kellene olvasnom..
igen, igen
nem tudom mióta van pontosan, pár hónapja fedeztem fel csak. nagyon hasznos, előfeldolgozóban így már aztán végképp könnyű mondjuk újraszervezni az egész $content.
-
clear: both;
Szintén ugyan ez a problémám.
Szintén ugyan ez a problémám. 2 napja keresem a megoldást erre a témára és még nem jöttem rá hogyan kell. A fenti hozzászólásokat elolvastam, de semmi........... nem lett megvilágosodás.
Van nekem 1 cck mezőm de nem tudom megjeleníteni a node-hirek.tpl.php - ben.
Drupal 5.x - így írja ki: Időpont: 2009. Október 07. (szerda) 18:00:pm
míg a
Drupal 6.x - alatt csak így tudom kiíratni: 2009. Október 07. (szerda) 18:00:pm
ezzel kapcsolatban megértem még egy oktató videót is :):) (Lullabot Learning CCK For Drupal) de nem lettem okosab. Valaki tudna segíteni ebben??
konkrétan
vagy:
vagy:
első kettő olyan kimenetet fog adni, amit a cck display fields fülén beállítottál, a harmadik meg csak kinyomja a mezőben az összes értéket.
az első kettő egyébként elhangzott a szálban korábban, kipróbáltad őket? mi történt? mi volt a hiba?
(legközelebb légyszi nyiss új témát az új kérdésednek)
-
clear: both;
Nagyon hálás vagyok, köszönöm
Nagyon hálás vagyok, köszönöm működik.
Aboros: az első kettő egyébként elhangzott a szálban korábban, kipróbáltad őket?
Viki: igen, először kipróbálom a dolgokat mindig és csak utána fordulok segítségért.
Aboros: mi történt?
Viki: semmi nem történt akkor ezért nem is értettem, hogy miért nem működik a dolog.
Aboros: mi volt a hiba?
Viki: hibajelenség nem volt így nem tudtam, hogy mi lehet a gond, ( egyszerűen nem jelenítette meg a dolgokat ) de most már működik így még 1x köszönöm a segítséget.
Ez így biztos korrekt?
Az utolsó ugye csak teszt jelleggel írtad le, mert én nem vagyok biztos benne, hogy a cck value értékeket csak úgy ki lehetne tolni a kimenetre. Egy check_plain() azért sokat dobna rajta.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
hu, teljesen igazad van
tényleg szoktam látni, hogy átküldik rajta. szinte soha nem írok ki mezőt field_valami[]['value'] módszerrel, azért is maradt le talán belőle. meg az is fontos szerintem, hogy te tudod mi van a meződben.
úgy értem, lehet, hogy egy olyan szövegmezőről van szó ami eleve plain text, akkor szerintem nem kell már a check_plain().
nem úgy van, hogy a legtöbb cck widget már bevitelkor szűri a bevitt értéket annak megfelelően, hogy mi engedélyezett? szóval, pl egy link mező url részébe nem nyomhatsz te csak úgy egy sql inject vagy igen?
vagy mindig kell check_plain() vagy hogy? egy imagefield value -ját nem nyomhatom át egy check_plain -en. vagy?
kicsit ez ködös. :) valami rémlik :), hogy a usertől kapott adatokat mindig illik ellenőrizni, de olyan sok minden lehet abban a value -ban (ahány mező annyiféle) meg olyan sok mindent lehet vele kezdeni (nem csak kiírni, más dolgokat is) hogy nem lehet általánosan mondani, hogy mindig át kell kergetned a check_plain() -en.
(jól logikázok vajon? talán rámszólsz ha nem és az jó:)
inkább csak a struktúrát akartam illusztrálni, hogy hol találja a mezőjét meg az értékeit. bár ezt ugye devel modullal is látni ;)
-
clear: both;
néhol döcög a logikád
A Drupal is azt az utat követi, hogy az adatbázisba azt tárolja amit a júzer beírt. Erre azért van szükség, mert ha szűröd akkor nem tudod visszatölteni neki amikor szerkeszteni akarja. Nem véletlenül nem használja ma már senki a magic_quotes=ON beállítást, hisz a webalkalmazásodnak kell eldöntenie, hogy mit kezd az adattal. Lehet az adatbázisba fogja írni (ekkor jól jön, ha MySQL és nem ha Oracle az adatbázis motorod) lehet, hogy megjeleníti (ekkor átkozni fogod, mert felesleges ' jelekkel lesz tele).
Előszűrésnek nincs értelme, mert azon a helyen nem tudhatod, mire lesz felhasználva. Pl. egy pdf-be betolva, vagy egy .txt-be, vagy akár egy mail body-ba már egészen más átalakítások szükségesek.
Egyszerű print-nél ökölszabályként jó a check_plain(), de mondjuk ha ezt egy href paraméter urljében akarod felhasználni, már check_url() a jobb megoldás.
Egyébként pont egy sima text mező ilyen formában való kiíratása tud nagyon veszélyes lenni. Szóval csak óvatosan.
Bővebben:
http://crackingdrupal.com/
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu