CCK vagy saját kód?

aKRON képe

Még most ismerkedek a Drupallal ezér lehet pontatlanul használom a fogalmakat, de értsétek jól :)
Csak annyi lenne a kérdésem, hogyha rendelkezek PHP ismeretekkel akkor célszerűbb-e a CCK modul helyet saját kódot írni? Pontosabban mikor érdemes (és mikor nem) a CCK-t használni? Itt a teljesítményre gondolok.

Kérdezhettem volna a views modult is. AZt sem látom még át teljesen.

- A -

(ez most buta kérdés volt? :)

pp képe

Attól függ mi a feladat. A Drupal egy általános célú tartalomkezelő rendszer, ugyanakkor "mindenre rávehető"*

Ha cck-val készítesz egy tartalom típust akkor annak lesz egy valamilyen adatbázis reprezentációja, mely nem biztos, hogy a feladat szempontjából a legoptimálisabb. (adatbázis szempontjából valószínűleg az. ;))

Pár ezres tételnél és napi 1000 látogatónál nem biztos, hogy érdemes saját modult írni.
A lényeg, hogy a feladattól függ, hisz lehet a cck-nál nem tudod optimálisabban megcsinálni, de lehet, hogy megtudod, sőt.

pp

* © Hojtsy Gábor

0
0
Illyés Edit képe

Szerintem a fő kérdés az, hogy mire kell a Drupal, ha az adataid kezelésére nem feltétlenül szükséges. Ha például csak a felhasználókezelést akarod a Drupalra bízni, akkor nyugodtan fejleszthetsz hozzá egyéni adatkezelési megoldásokat. De ha kell fejlett jogosultságkezelés, workflow, listázási funkciók (Views), eseménynaptár integrálás és még 10 másik funkció, ezek többnyire a node koncepcióra épülnek, tehát ha nem node-ként tárolod az adataidat, akkor ezeket a funkciókat nagy valószínűséggel el fogod veszíteni.

Teljesítmény szempontjából az olyan megoldások problémásak, amikor mondjuk van egy CCK tartalomtípusod, aminek az egyik mezője egy Views listát tartalmaz, aminek az elemei CCK tartalomtípusok mezői, amelyek megint csak listákat tartalmaznak, stb. stb...

0
0
aKRON képe

Köszönöm! Tetszett Gábor copyright-ja :)

Azért tapogatózok, hogy el tudjam dönteni merre induljak. A modulfejlesztés dolgait is jó idő megtanulni, a CCK és View modulok átrágása is sok idő. Úgy veszem ki a CKK-val gyorsabb haladni, és esetleg később más is könnyebben tudja tovább vinni a munkát (munkahelyen belül). Viszont egyenlőre nem látom meddig lehet vele elmenni, mit lehet kihozni belőle. Viszont szeretném elkezdeni a munkát és az meg kényelmetlen lenne ha hónapok múlva derül ki, hogy a másik út lett volna jobb :)

Ez a node koncepció érdekel. Lehet erről olvasni magyarul valahol? ...utánna már az angollal is jobban boldogulok. Azért saját modulból is lehet ráépíteni nem?

Most a felhasználó és jogosultság kezelés amire leginkább szükségem van.

0
0
aboros képe

szerintem a cck -val nagyjából 'bármeddig' el lehet menni, kreativitás kérdése. szerintem érdemes a cck -val kezdeni, akkor is, ha tapasztalt php -s vagy. (bár olyat is ismerek aki szerint a views olyan, mintha ágyúval lőnél verébre:)

valójában saját tartalom típusokat definiálhatsz, a neked tetsző mezőkkel. jogosultság szinten minden létrehozott tartalom típusra külön létrejönnek a köv jogosultságok: 'create' 'edit' 'edit own' szóval típusonként tudod állítani, hogy az adott típust mely csoportok hozhatják létre, szerkeszthetik az adott típusú tartalmat (tekintet nélkül arra, hogy ki hozta létre), illetve szerkeszthetik az adott típusú tartalmat, de csak azokat a node-okat, melyeket ők hoztak létre.

0
0

-
clear: both;

Illyés Edit képe

Viszont egyenlőre nem látom meddig lehet vele elmenni, mit lehet kihozni belőle. Viszont szeretném elkezdeni a munkát és az meg kényelmetlen lenne ha hónapok múlva derül ki, hogy a másik út lett volna jobb :)

Ha leírod a feladatot (a.k.a. "specifikáció"), akkor általánosságok helyett konkrétan is meg tudjuk mondani, hogy mi merre indulnánk el. Aztán persze lehet, hogy mi is melléfognánk... :)

0
0
aKRON képe

Más dolgaim miatt mostanában térek vissza a Drupálhoz.
Meglévő siteunkat szeretnénk korszerűsíteni, átültetni Drupálra. Napi kb. 15 ezer oldalletöltés. A pontos specifikációt azért nem írom le, mert általánosságban (is) érdekel a téma.

Tételezzük fel, hogy a node koncepció megfelelő a feladathoz.
Tehát nem az a kérdés, hogy node vagy nem node. Hanem hogy ezt CCK-val készítsem el, vagy saját modullal. Ez utóbbi mód sem túl bonyolult. De ahogy nézem a CCK is hasonló dolgot művel, mintha kézzel kódolnám le, de pl. egy verzióváltás - 5-ről 6-ra :) kevesebb vessződséggel jár CCK-val.

Viszont a views-al már nem vagyok ilyen nyugodt. A legtöbb esetben egy SQL utasítással és pár soros kóddal kiváltható (vagy ezt rosszul látom?).
Tesztelni vagy mérni nem tudtam, de az az érzésem, hogy sokkal nagyobb erőforrást igényel a site ezen modulok használatával, mint nélkülük. Valós lehet egy ilyen félelem?

0
0
pp képe

ott majd leírom bővebben, hogy nyílván, de mit is vártál? Jóóóreggelt csodák nincsenek.

pp

0
0
aKRON képe

Azért nem nyitottam új témát, mert nem az ...szerintem :) - csak folytatom

A "nyilván" is világos, csak az nem, hogy mennyire "nyilván"? Lehet nem érdemes ezen görcsölni napi 100ezer oldalletöltés alatt és akkor nem aggódok, de lehet már 10ezer oldalletöltésnél sok gondot kikerülök azzal, ha inkább lekódolom. Szóval ilyesmi érdekelt volna. (Ja! És a tárhelyet hostoljuk, vagyis nem csak a mi oldalainkat szolgálja ki.)

0
0
pp képe

a téma címe "CCK vagy saját kód", te meg a Views-ról kérdezel, no de mindegy.

Fentebb leírtam, hogy általánosságokban nem lehet válaszolni. Alapvetően célfeladatra célprogramot írva sokkal optimálisabb eredményt lehet elérni, ezen nincs mit pörögni.

A CCK és a Views meg egy általános célú modul, számos kompromisszummal. Feladatom volt, hogy egy apróhirdetés szerű kereső oldalt rakjak össze. Ezt pikk-pakk össze lehet kattintani a cck-views modullal, de belenézve a forrásba és megvizsgálva az adatbázis szerkezetet a feladathoz nem a legoptimálisabb választás volt a páros. Más feladatokhoz tudom ajánlani, de ehhez nem, vagy csak megfelelő adatbázis módosítgatás után. (és akkor elveszítjük a webes felületen összekattintom és csókolom érzést)

A lényeg konkrét feladat konkrét válasz, általános feladat általános válasz.

pp

0
0
Illyés Edit képe

Az egyik legfontosabb dolog amit végig kell gondolni, az a felhasználók menedzselése. A nem regisztrált felhasználó cache-ből kapja a tartalmakat, a regisztráltnak minden egyes oldalt frissen rak össze a Drupal. Nagyot lehet hasraesni identitás-zavaros projektekkel, amikor pl. nem tudjuk eldönteni, hogy most hírportált üzemeltetünk, vagy közösségi portált. Bonyolult hírportálos listázó blokkokat teszünk ki nagyszámú regisztrált felhasználónak, akiket aztán élesben kell kiszolgálni. Láttunk erre példákat az utóbbi időben.

Vannak technikák, amelyekkel meg lehet próbálni menedzselni az ilyen helyzeteket is (Block Cache, felhasználói aktivitást igénylő oldalak elkülönítése-kiszervezése, stb. ) De ezek már kényszermegoldások.

A Views-t is lehet okosan használni (listázó nézet), meg nem okosan (teaser nézet). Mérlegelni is kell olykor, pl. a sima filteres view-kat betárazza, az argumentumosakat futtatáskor élesben rakja össze – másrészt viszont könnyen előfordulhat, hogy 5-6 jól átgondolt argumentumos nézetre fel lehet húzni egy egész portált, toronyórával, lánccal. Egy összetettebb webhely kézzel írt lekérdezésekkel olyan, mint a nagymama konyhaszekrénye – minden zugban van valami finomság – ezt aztán tartsa karban akinek két anyja van.

Napi többszáz-ezer oldalletöltésnél viszont már a cache sincs ingyen, ott már nagyon kell számolni.

0
0
pp képe

A Views-t is lehet okosan használni (listázó nézet), meg nem okosan (teaser nézet).

Arra gondolsz, hogy a list és table nézetben "egy lekérdezéssel" kapja meg a views az összes adatot, míg a teaser nézetnél minden egyes találati sorhoz még meghívja a node_load függvényt, mely további számos lekérdezést generál?

Erre mondhatjuk azt, amit fent mondtál, de ez sem igaz mindig. A CCK ugyanis kizárólag a vid szerint indexeli a tábláit, az adat tartalom szerint viszont nem. Amikor Te nem a node táblában található infók alapján keresel(létrehozás dátuma, típus, létrehozó stb.) és esetleg nem csak egy hanem több olyan mező szerint amik több értéket is felvehetnek(külön tábla) akkor az egyetlen egy query jóval tovább tarthat, mint akár 1000 node_load. Na de ha lesz időm akkor majd végzek erre vonatkozó méréseket.

Tipikusan olyan kérdés ez, hogy amikor elindul egy oldal és tök jól működik majd elérve a kritikus számot 100-1000 (feladattól és rendelkezésre álló erőforrástól függően) egyszer csak lassul, majd egyáltalán nem működik az oldal.

A fenti mondat tehát igaz, nagy általánosságokban, de vannak olyan spec esetek amikor nem. Tipikusan amikor a views felfedett szűrőit kezdi el használni az ember, de ha jól értem Te nem erre gondoltál.

Abba a vitába pedig szerintem szintén nem érdemes belemenni, hogy views, vagy saját kód, mert mindkettőre lehet olyan szélsőséges példát találni, ahol az egyik vagy másik az üdvözítő.

pp

0
0
Illyés Edit képe

Arra gondolsz, hogy a list és table nézetben "egy lekérdezéssel" kapja meg a views az összes adatot, míg a teaser nézetnél minden egyes találati sorhoz még meghívja a node_load függvényt, mely további számos lekérdezést generál?

Erre mondhatjuk azt, amit fent mondtál, de ez sem igaz mindig.

Igen, én itt a legegyszerűbb esetre gondoltam, amikor készítünk pl. egy egyszerű taxonómia listát blokkba, akkor a teaser nézet többnyire teljesen feleslegesen node_load-ol.

Érdemes elolvasni ez a jó kis odamondogatós vitát a Views fejlesztő blogján.

Also, I highly recommend using List views where possible, since you can avoid node_loads. In fact, Karoly Negyesi went so far as to write a little nodeapi hook that stores the fully converted teaser in the database so that he could utilize a List view as as teaser view. Something that is ordinarily not possible because teasers have to be processed. With a little nodeapi magic, however, he actually gained significant efficiency using Views.

De nincs köztünk vita ebben, meg kell nézni mit csinál a Views, nem ész nélkül kattintgatni, és eldönteni, hogy elfogadható teljesítményt nyújt-e, az egyszerűbb karbantartás megér-e ennyi teljesítményromlást. Ezt csak esetileg lehet eldönteni, nyilván a kérdező ismeri az összes szempontot, úgyhogy mi itt csak általánosságokat tudunk mondani.

0
0
aKRON képe

Köszönöm a válaszokat (István: tudtam h. a cim a hibás :) de már a felvetésben is megemlítettem a views-t )

Köszönöm Edit válaszát is. Hiányoznak ezek a belső működéssel kapcsolatos infók. Ezek sokat tudnak segíteni a tervezésben.

0
0