Posted by ztyx on June 17, 2008 at 6:24pm
Hejhej,
Jag skickar en kanske alltför luddig fråga som har gnagt inom mig länge:
CCK låter hippt, ballt och flexibelt - man kan skapa vilka nodtyper som helst och det interagerar finfint med Views. Men när är det dags att börja dra i nödstoppet och programmatiskt skapa sin egen nodtyp? Sacha chua:s blogginlägg hintade att CCK inte är lätt att importera/exportera. Vad är andra för-/nackdelar?
...eller vågar någon till och med påstå att det alltid i det långa loppet är bättre att skapa sin nodtyp programmatiskt?
Jens
Comments
Nackdelen med CCK är väl
Nackdelen med CCK är väl att man får lite sämre prestanda. Men på en normal site med sidcachen aktiv är det inget problem. 99 % av alla case kan lösas med CCK vill jag påstå.
Om man vill skapa en nodtyp som 1) kräver specifik programlogik, 2) måste vara snabb och minneseffektiv 3), inte kommer att behöva ändras alltför mycket i efterhand och/eller 4) behöver kunna distribueras till många sajter – då är en egenutvecklad nodtyp rätt val. (Därmed inte sagt att man inte kan integrera egen programlogik med CCK-fält, men det är inte nödvändigtvis lättaste sättet.)
En annan sak att tänka på är att man faktiskt kan kombinera båda metoderna.
/ Hannes Lilljequist – SthlmConnection
En annan sak att tänka på
Hur menar du? Att vissa nodtyper är CCK-noder och andra inte?
Nä, jag menar att även
Nä, jag menar att även nodtyper som är skapade av moduler kan använda CCK-fält. Man skulle till exempel kunna lägga till ett bildfält i nodtypen forum med hjälp av CCK.
/ Hannes Lilljequist – SthlmConnection
Om Sacha Chua:s inlägg samt exempel när CCK inte är bäst
Hannes (zoo33) har som alltid helt rätt. Så jag skall bara kommentera Sacha Chua:s blogginlägg samt ge ett exempel på när CCK inte är lämplig. Jag börjar med det sista först.
Jag och min kollega (Jakob alias Solipsist) var hos en kund idag för att ge lite råd om vilka vägar de skall gå i fråga om sin Drupal utveckling. Bland annat hade de behov av att skapa en nodtyp utan brödtext men med en massa olika fält som användaren kan fylla i. En del av dessa fält var obligatorisk. Andra var det inte. Några skall bara fyllas i om något annat har fyllts i o.s.v. Vi kom fram till att de behövde dela upp nodformuläret i flera flikar, som man skall kunna hoppa fram och tillbaka mellan som man önskar, och den så långt ifyllda datan skal sparas i databasen mellan varje hopp (normalt flyttas data bara med och sparas först på slutet). Exakt hur många flikar som visas och vad dessa innehåller beror på uppgifter som användaren lämnar på den första fliken, som blir den enda som måste fyllas i. Denna lösning går att bygga i CCK, men det skulle bli grymt kmplicerat och väldigt bräckligt. I detta fall är det helt överlägset att skriva en modul som tillhandahåller denna speciella nodtyp. Men precis som Hannes säger, i 99% av fallen så är det CCK som gäller idag.
Det är inte svårt att importera/exportera CCK -- tvärtom är det ruskigt enkelt. Så här exporterar du: slå på Content Copy som medföljer CCK, gå till admin/content/types välj Export eller Import och följ de mycket enkla instruktionerna. Det som Sacha diskuterar är möjligheten att skriva program som automatiskt skapar nodtyper med CCK, s.k. programatisk import. Det är svårt, för att inte säga nästan omöjligt med dagens CCK. Men med mycket hack så går det. Ett exempel på detta är CivicSpaces hosted Drupal profiles. Det är en lösning för att installera, konfigurera och uppdatera Drupalbaserade webbplatser. Denna lösning skiljer sig från t.ex. SifBuilder, AutoPilot och Drool genom att vara den enda som kan fånga och sen återskapa en webbplats helt programatiskt.
Thomas Barregren – Webbredaktören