Salve, sono nuovo del mondo drupal. Nell'ultima settimana ho installato la versione 6 e ho cominciato a studiarmelo un pò. Effettivamente seguendo la documentazione sul sito ufficiale ho compreso molte cose dei meccanismi interni di drupal e non avendo usato altri CMS ho potuto evitare la confusione dovuta a conoscenze pregresse.
La questione è semplice. Sto sviluppando un sito web contenente recensioni. Il mio scopo è di ottenere il massimo di performance e anche di imparare, per questi motivi ho dato un'occhiata rapida a CCK, Views, Panels, Frontpage, ecc.... ma li ho accantonati e ho preferito programmare i miei moduli.
Ho realizzato un modulo che implementa un nuovo node type con i campi che mi interessano e funziona benissimo...posso inserire nuove recensioni, visualizzarle ( ho implementato hook_view a questo proposito ), cancellarle, ricercarle, ordinarle, ecc...
Il problema, o meglio la curiosità, è nato nel momento in cui mi sono trovato a dover implementare una homepage personalizzata, totalmente diversa da quella di default. Ho capito che devo andare in admin/settings/site-information e Default front page e settare "startpage" ( è questo il path che uso per la mia homepage )
Poi ho ovviamente implementato in maniera adeguata l'hook menu
function myreviewer_menu() {
$items['startpage'] = array(
'title' => t('My custom homepage'),
'page callback' => 'myreviewer_homepage',
'access arguments' => array('access content')
);
return $items;
}la funzione myreviewer_homepage si presenta così
function myreviewer_homepage() {
return "ok, it works!!!";
}fin qui tutto ok, la stringa in questione viene messa al posto di $content
a questo punto però voglio approfondire i meccanismi interni che portano alla creazione e riempimenot di $content....ho dato un'occhiata a node.module, funzione node_page_default....questa funzione fa in pratica la stessa cosa che faccio io, cioè crea il contenuto e lo restituisce con un return
però a questo punto come fa drupal a sapere che questo contenuto va assegnato a $content? come fa a sapere che io nel tema userò proprio $content per stoccare il contenuto? e perchè non assegna questo contenuto per esempio a $left, $right, $header o $footer?
suppongo che le 5 regions citate siano hardcoded nel sistema
ovviamente io posso aggiungerne altre, rimuovere quelle di default....e che succede se nel mio tema cambio il nome della regione "content" in "mickymouse"??? come fa lui a sapere che il contenuto restituito da myreviewer_homepage non va inserito in $content ma in $mickymouse???
suppongo di dover creare un file template.php e usare l'overriding per istanziare e popolare la variabile $mickymouse, giusto!?!
quindi se ho capito bene le 5 variabili ( $content, $left, $right, $header e $footer ) vengono create di default qualora io non abbia definito esplicitamente delle regions nel mio tema
e che in virtù di ciò, il sistema di templating sa a priori che di default io userò $content nel tema e che l'output delle funzioni che generano i contenuti va ficcato in $content
a questo proposito ho notato infatti che le altre 4 regioni non vengono popolate di default, ma solo se esplicitamente nell'interfaccia admin ci si mettono dentro dei blocchi...
e infine, qual'è la funzione che implementa questo meccanismo di popolamento di $content?
Bravo è assurdo usure cck se si è programmatori, specie se si vuol fare cose particolari. Questo è il mio personalissimo pensiero. :-)
Ciò che hai fatto è corretto. Ti consiglio anche di guardare bene anche come temizzare il tuo nodo e vedere bene l'hook_theme
....ma non hai dato un occhiata a includes/theme.inc ;-)
template_preprocess_*
Per il discorso regioni, guardati la documentazione su drupal.it
Ciao
Gianni
Gianni... in tutte le salse ce l'hai detto che non ti piace usare i moduli preconfezionati (a Milano non dicevi altro... ;))
Come però ci siamo anche risposti tutti, dipende sempre da quello che devi fare. Se progetti un modulo completamente nuovo le cui funzionalità non esistono, meglio programmare. Altrimenti... perchè reinventare la ruota?
Si, è vero, c'è il problema performance. Ma è un falso problema. Se ottimizzi bene (dappertutto, php, apache, moduli, css, javascript, boost...), ottieni risultati impressionanti (fatti un giro su www.nuovofiscooggi.it.... quello che vedi è tutto cck).
Alessandro
nel mio caso la scelta è dovuta principalmente alla necessità di prendere il toro per le corna, nel senso di imparare il più possibile di Drupal, visto che negli ultimi 4 anni mi sono avvicinato più volte a questo CMS ma l'ho sempre abbandonato per mancanza di tempo e voglia di smanettarci....
ultimamente a causa della mania web 2.0, ajax, div che appaiono e scompaiono e compagnia mi sono trovato a dover sudare sempre di più per costruire siti web e allora ho deciso che partire da un CMS maturo e potente come Drupal ti aiuta a semplificare il lavoro di almeno il 60%
però proprio perchè sono nuovo a questo CMS ho deciso di approfondire il più possibile gli internals
poi ho dovuto rinunciare anche perchè Panels per la versione 6 è in alpha e non volendo fare il downgrade alla 5 ho pensato di poter programmare i moduli che mi servono a mano
devo ammettere che Drupal è davvero molto molto interessante e man mano che scendo nei dettagli e analizzo tutte le sue intercapedini, comincio a comprendere la sua vera potenza
comunque mi avete tolto un peso dallo stomaco, cominciavo a credere ci fosse qualcosa di magico nel layer di theming :D
Non reinventi la ruota...... permettimi di dire che il tuo è un concetto errato. :-) :
Il nodo è un oggetto e per sua natura è fatto per ottenere nuovi con proprietà e metodi differenti. I nuovi oggetti li crei facendo nuove tipologie di nodo e relativo codice. Quindi non reiventi la ruota ma ne espandi le possibilità. E' la trasposizione del concetto di OOP su drupal:
http://api.drupal.org/api/file/developer/topics/oop.html/6
Proprio perchè esiste questo concetto, non sono costretto a "reiventare la ruota" ma ad adeguarla alle mie necessità.
Casomai è CCK che limita l'espandibilità del nodo limitandole possibilità offerte e non permettendo l'aggiunta di nuovi metodi (senza scrivere moduli).
Poi, francamente, da programmatore, preferisco lavorare con tabelle, campi e query sql anzichè con una struttura fisica definita dal programma specifico (in questo caso CCK) e non esportabile ne su altri siti drupal ne tantomeno su altri programmi. Ricordati che gli algoritmi e le strutture delle tabelle li puoi riapplicare su altri linguaggi ed ambienti.... CCK e fine a se stesso (o meglio a Drupal) :-)
Quindi cck fa schifo? no, non dico questo. E' uno strumento utile per i non programmatori ma nulla più. Tutto IMO ovviamente
cck + VIEWS.... diciamo le cose come stanno ;-)
Views lo puoi usare anche con i tuoi moduli creati da zero.
Bel lavoro, ma non c'è nulla che non potevi fare via codice (codice che poi avresti avutoi disponibile per altre applicazioni e codice a sua volta espandibile). Le temizzazioni del dato, ti son costate la stessa identica fatica della temizzazione di un qualsiasi nodo.... forse hai guadagnato un po' di tempo usando anche altri moduli per cck, ma ricordati che tutto ciò ha un prezzo: se ti capiterà di cambiare ambiente/versione saranno dolori.... come saranno dolori se un giorno cck andrà a morire. Personalmente questi problemi li ho già vissuti con altri strumenti.
Ciao
Gianni
Mah... da ex-programmatore-orgoglioso a programmatore-orgoglioso, penso che qui oltre che reinventare la ruota, ci mettiamo tutti e due sulla ruota del criceto e iniziamo l'ennesima discussione sterile.
Preferisco dire che nessuno dei due sbaglia se e quando non carica le frasi con "io ho ragione tu hai torto". Tutto quello che scrivi è vero. Il mio è un discorso di opportunità legato a bisogni aziendali (il progetto è nato e cresciuto nei ritagli di tempo) quindi da bravo ingegnere dovevo concentrarmi sull'analisi e non sull'implementazione. L'analisi mi ha portato ad una decisione di usare e riusare/modificare/estendere moduli già esistenti. Decisione opinabile, ma per me giusta. Senz'altro ne ho guadagno in TEMPO (variabile sempre preziosa). Qualità scadente? Uhm... ti garantisco che non si è lamentato nessuno, anzi! ;)
Tu stai parlando come impiegato di quell'azienda. Quindi hai un progetto non esportabile che ha richiesto un anno di sviluppo (lo leggo dal tuo blog).... ti sei fatto un "vestito su misura".
La differenza tra me e te è che tu hai quei progetti aziendali e basta. Non hai bisogno di crearti degli strumenti riutilizzabili perchè quelli hanno un utilizzo limitato all'azienda. Per me è diverso.... fare moduli significa RIUTILIZZO del lavoro e non reinventare la ruota. CCK non è ESPORTABILE. Le strutture che crei NON le puoi esportare da un'altra parte.
E poi, sinceramente, basta con la frase "reinventare la ruota", se hai fatto un po di programmazione OOP dovresti sapere che i concetti OOP nascono proprio dal concetto di NON reinventare la ruota. :-) , di conseguenza il concetto di nodo e sviluppo del nodo tramite moduli, segue quei concetti.
Per curiosità, prova a vederti il piccolo modulino che ho fatto.... semplice semplice proprio per far vedere le funzioni. Guardati le sue funzioni e vedrai che drupal ha le api appositamente studiate per rendere semplicissimo lo sviluppo di nuovi moduli, senza reinventare nulla.
Dove hai letto "qualità scadente"? non mettere frasi che non ho mai detto :-) , casomai ho detto e ribadisco "Bel lavoro".
P.S.
La mia non è una discussione sterile (stò solo rispondendo ai tuoi post) e non sono un programmatore orgoglioso ma un programmatore di professione il che è molto diverso. Cerchiamo di tenere terminologie "corrette" ;-)
con amicizia
Ciao
Gianni
Nei ritagli di tempo, stò sviluppando la versione 2 di un programmino che ho fatto, per la generazione automatica di moduli. Appena l'ho finito, ti avviso. Genera moduli sia come espansione di nodo che come modulo a se stante, per la gestione di dati da una tabella. Crea automaticamente tutto il codice necessario al modulo per l'installazione, l'inserimento/modifica/ricerca di dati della tabella e non solo...... pazientate ancora per qualche settimana e vedrete il risultato.
Ciao
Gianni
E va beh... c'ho provato. ;)
Davvero ho scritto un anno di sviluppo? Ops... ho sbagliato. Un anno da quando è partito il progetto. Madonna mia, davvero un sacco di tempo. Ma il cliente, quando capisce le potenzialità, cambia sempre idea, e poi c'era la gara per l'hosting da gestire, .... E come puoi dire di no ai tuoi capi?
Cmq... non so da che derivano altre affermazioni, ma cck è esportabile (come tipo di dato e come contenuti). Si, occorre giocherellarci un po' su... ma l'ho fatto anche perché sto importando i dati del vecchio FiscoOggi (e se no che 'Nuovo' era?).
Cmq il tuo modulo, ottimo, lo mostravi su a Milano (penso fosse quello, con il form che si popolava dinamicamente). Anch'io mi diverto un sacco con le API di Drupal, però... che dirti, preferisco concentrarmi su altri aspetti. Forse è perché la programmazione, dopo tanti/troppi anni mi è venuta un po' a noia...
Ti capisco benissimo.... ;-)
Esportabile significa molte cose.... ma preferisco tagliare quì. :-)
Io la amo ancora, benchè programmi dal 1989. Certo, ci sono 1000 lavori decisamente migliori, ma programmare non è malaccio.
Ciao
Gianni