Kezdő kérdés a CCK modulról

fox mulder képe

Sziasztok!

Jól sejtem, hogy a CCK modullal tetszőleges adatmodell imitálható? Ha igen, akkor nem veszítek-e sokat a teljesítményből azáltal, hogy megkerülöm az SQL és PHP kódolást és egy absztrakt szinten modellezem az adatbázist? Ha nem, akkor van-e olyan modul a Drupalhoz ami ezt tudja. Ha nincs ilyen, akkor kénytelen leszek (és ez nem fenyegetés :) ) a konkrét problémámnak új témát nyitni.

Köszönet

pp képe

Sajnos a cck a lehető legáltalánosabb adatmodellt használja. Ezért bár vele a fejlesztés gyors és egyszerű, az eredmény sose lesz optimális. (pl egy apróhírdetés oldalt össze tudsz vele kattintgatni, csak legyen szervered(inkább szerver parkod), ami kiszolgálja a kéréseket)

pp

0
0
fox mulder képe

...ha van egy speckó adatmodellem, ami nem tartalmazza az olyan alap dolgokat mint user-ek, jogok, cikkek, hírek (mert ugye ezeket a Drupal csípőből vágja), akkor saját modult kell írnom, vagy keresni a több százból olyat, amelyik alkalmas a megvalósításra?

0
0

Fox Mulder

pp képe

Igen, de nem olyan bonyolult ;)

pp

0
0
fox mulder képe

:)

0
0

Fox Mulder

aries képe

Általános szabály, hogy próbáld meg előbb elkészíteni a feladatot és azután optimalizálni. Az esetek döntő többségében nem is kell.

0
0
pp képe

Ez amolyan inkrementális fejlesztési elv, ami sose vezet el optimális megoldáshoz.

Gondos tervezés és mérlegelés kell, hogy megelőzze a munkát. Számos esetben a fenti módszer nem vezethet sőt nem is vezet optimális eredményhez. Számos olyan projekt van, ami ugyan működik és nem optimális, ami azt jelenti, hogy 10000 node felett használhatatlan. Ezt aztán csak úgy lehet "optimalizálni", ha az egész alkalmazást újratervezzük és nulláról elkészítjük.

0
0
aries képe

Nem azt írtam, hogy nem kell megtervezni, vagy legalább végiggondolni, hanem hogy nem az elején kell optimalizálni. Ha optimális megoldást keresnénk, akkor assemblyben nyomnánk. De maradjunk a földön, ahol minden tegnapra kell. Nem kívánom a tanárurat kioktatni, úgyis tudja, miről beszélek, csak megint kötekedni tetszik ;)

0
0
fox mulder képe

Ha szabad, pontosítanám a feladatot (nincs határidő, hobbi az egész, de...).

Egy növényhatározóból indultam el. Regisztrált felhasználók (amatőr botanikusok) fajokat gyűjtenek (fotókkal, leírásokkal, mint a Wikipédián). Ezeket tulajdonságokkal ruházzák fel, ezáltal a még amatőrebb érdeklődőknek (anonim látogatók) egy rakat formot biztosítanak ahhoz, hogy azok a fajokhoz kapcsolt tulajdonságok alapján megkereshessenek egy számukra ismeretlen fajt. A fajokhoz tetszőleges számú tulajdonság rendelhető (vagyis a FAJOK tábla nem `tulajdonság_1`, `tulajdonság_2` stb mezőkkel rendelkezik, hanem van egy TULAJDONSÁGOK tábla is és a FAJOK-TULAJDONSÁGOK kapcsolat M:N). Mivel gyakran ismétlődnek az olyan tulajdonság nevek mint: 'szirom színe', 'szirom hossza', 'szirom szélessége', 'szirom alakja' stb, ezért létrehoztam egy ALKOTÓRÉSZEK táblát is (és itt még egy pár ilyen okoskodás alapján létrehozott tábla van), valamint arra gondoltam, hogy mi lenne, ha általánosítanám a feladatot és kiterjeszteném minden olyan dologra, amiből sok van és ezek közül keresünk egyet (bélyegek, ingatlanok, tüskésbőrűek, akármi), a hozzá rendelt tulajdonságok alapján. Vagyis van egy adatmodell mag, amit köríteni kéne jogosultság kezeléssel, fórummal, többnyelvűsíthető felülettel és tartalommal és az egyéb tipikus webes dolgokkal. Ehhez az egész kócerájhoz keresem azt az eszközt (framework, CMS), ami megoldja a tipikus webes feladatok rutinfeladatát, ugyanakkor kellő szabadságot biztosít a konkrét célkitűzéshez.

A Drupal kiváló eszköznek tűnik. Egyelőre CCK-val próbálkozom (növényfajok tartalomtípus, a tulajdonságok mint mezők). A Palócz tanár úr által említett 10000-es szám azonban inkább saját (remélhetőleg a CCK-nál gyorsabb) modul felé terel (Mo.-n ugyan csak kb. 2300 növényfaj van, de a tulajdonságok száma kb. 30-40 (~100), és egyébként is nagyralátó terveim vannak, a Földön kb. 700.000 növényfaj él).

Lényeg a lényeg: ilyen paraméterek mellett szerintem is előre el kéne dönteni, hogy melyik úton indulunk el. Kérdések ezek után:
Lehet-e lényegesen optimálisabb egy saját modul, mint a CCK+felfedett mezőkkel teletömött nézet kombó (ha jól értettem, ez Palócz T. Ú. javaslata)?
Menjek a fenébe és keressek egy framework-öt :)

0
0

Fox Mulder

pp képe

Röviden:
Kezdetben jó lesz neked a cck+view, de ha beindul a dolog mindenképpen újra kell gondolnod az egészet. Elkészítési időre és működési időre is lehet optimalizálni. Az elején nyilván az elkészítési időre kell koncentrálni, a végén meg a működésire. A lényeg, hogy tudjuk azt mikor kell váltani. (amikor még lehet ugye ;))

pp
(bővebben is kifejtem, hogy ne legyen ellentmondás a két hozzászólásom között, de most erre nincs időm ;))

0
0