Perchè odio Drupal

non è orientato ad oggetti ma piuttosto ad eventi, questo è una cosa che non mi piace.
Altra cosa che non mi piace è la modalità di realizzazione dei Moduli, è tutto troppo incasinato, vorrei più "modularità" all'interno di un modulo stesso, ad esempio alcuni specifici Hook_prepocess_*() in file come preprocess.name_module.module .... non so se ho reso l'idea, questa modalità renderebbe i moduli più facile da "leggere" e fare manutenzione.

Penso che tu lo stia vedendo solo dal punto di vista del theming in un approccio non enterprise.
Se ogni pagina potesse avere decine di file che ne modificano il flusso il server passa mezza giornata a giocare a pollicino invece di darti la maledetta pagina!

Uccio wrote:

Penso che tu lo stia vedendo solo dal punto di vista del theming in un approccio non enterprise.
Se ogni pagina potesse avere decine di file che ne modificano il flusso il server passa mezza giornata a giocare a pollicino invece di darti la maledetta pagina!

jhl.verona wrote:

Comunque al DrupalCamp Mavimo aveva messo un dito su una piaga del 'theming' di Drupal, Ricordi?
Mavimo: 'Chi usa il form API di Drupal?' - metà del gruppo
Mavimo: 'Chi è contento del form presentato nel browser?' - non tanti
Mavimo: 'Chi ha provato modificare il form dal API per migliorare la presentazione nel browser?' - pocchi o nessuno
(Non ho preso appunti, quindi non posso garantire le parole esatte)
Morale della favola? Chi fa theming vuole creare forms 'più belli' ma non è una cosa facile - o almeno è così che ho interpretato il discorso.

John

Da un lato avevamo le aziende che com'è immaginabile "chiedono" al grafico di disegnare qualcosa ed il programmatore o il themer dovrà provvedere a renderlo possibile, però ci si scontra in questo caso con l'anatomia di Drupal che nel caso dei FORM è più marcata che in altre sue componenti, probabilmente data la loro delicatezza. Infatti i Form sono soggetti ad attacchi, i form vengono utulizzati per il passagio di variabili... ecc in quest'ottica se ne comprende la loro complessità e la difficoltà nel renderli più elastici possibili e allo stesso tempo temizzabili facilmente.

Dall'altro lato abbiamo i grafici che molto spesso creano Form dalle forme particolari o dall'aspetto particolare, magari più usabili o semplicemente in linea con la grafica del sito...

I form non sono soltanto codice HTML stampato e temizzato, essi devono ricevere delle variabili, hanno molti attributi, spesso allocano delle variabili e personalmente mi sembra di capire che il Team di Drupal abbia dato più importanza al loro funzionamento generale e il loro utilizzo, ed in secondo luogo ne hanno progettato una loro possibile temizazzione, forse scavando nel loro utilizzo a piccoli passi si potrebbe renderli più usabili rispetto ad oggi.

beh prima di lamentarvi dei form di Drupal, provate quelli di Zend! :D

@jhl.verona: si grossomodo il discorso era quello, ma non ho capito bene (o per lo meno spero di non aver capito) se il problema è dato dal fatto che alla fne ci si accontenta o non si vuole fare un investimento nel trovare il modo di modificarlo. Alla fine una volat imparato il meccanismo non è complesso, più essere noioso, sembrare antimpatico, ma di certo non meno di altri sistemi. Personalmente ODIO strumenti in cui sono costretto a scrivere

Una cosa che non apprezzo al 100% di Drupal? Tutto e nulla, a volta il debugging è un pò incasinato, essendo ad eventi è abbastanza semplice seguirne il flusso, ma al contempo quandotrovi un erroe risalire a dove è partito è bloccante. E' procedurale e non ad oggetti (per lo meno non nel senso stretto del termine) e per alcuni è un difetto, sotto altri aspetti un pregio (omissis/silent akl camp l'ha dichairato apertamente nella sua lotta al PDO).

Poi ovviamente come tutti gli strumenti ha diverse pecche e punti a suo favore, ma un volta che lo si conosce si sa anche dove andare a parare..

Gli oggetti sono il male! Scherzi a parte, trovo che l' object orientation venga considerata come la panacea ai mali della programmazione, il che mi fa accapponare la pelle vedendo poi come la gente la usa. Programmare ad oggetti NON vuol dire saper programmare, cosi come chi sostiene che "si programma ad oggetti perche' e' cosi che si fa" molto spesso sta parlando a vanvera e dimostra semplicemente la sottomissione ad un dogma. La programmazione a oggetti va utilizzata quando serve, non a prescindere dal contesto e SOPRATTUTTO se la si sa usare, ricordando che il suo principale scopo e' quello di fornire uno strumento di modellazione dei problemi che ricalchi piu' da vicino il mondo reale.
Vi faccio un esempio che mi sono trovato pochi giorni fa davanti ricontrollando codice che mi ha fatto rizzare i capelli:

<?php
class Goom_Mail_Client {
    protected $_mail;
    public function __construct($bounce, $name) {
        Zend_Mail::setDefaultTransport(new Zend_Mail_Transport_Sendmail('-f ' . $bounce));
        $this->_mail = new Zend_Mail('utf-8');
        $this->_mail->setFrom($bounce, $name);
    }
    protected function setMail(Zend_Mail $mail) {
        $this->_mail = $mail;
        return $this;
    }
    protected function getMail() {
        return $this->_mail;
    }
    public function addTo($email, $name) {
        $this->_mail->addTo($email, $name);
        return $this;
    }
    public function addBcc($email, $name) {
        $this->_mail->addBcc($email, $name);
        return $this;
    }
    public function setSubject($subject) {
        $this->_mail->setSubject($subject);
        return $this;
    }
    public function setBody($text, $html = null) {
        if (isset($html)) {
            $this->_mail->setBodyHtml($html);
        }
        $this->_mail->setBodyText($text);
        return $this;
    }
    public function send() {
        $this->_mail->send();
    }
}
 
?>

Questo e' un esempio di cosa voglia dire non capire il significato dell' object orientation: la classe e' assolutamente inutile in quanto non aggiunge nulla alla classe istanziata nel costruttore ed e' stata messa li' solo per avere una classe chiamata Goom_Mail anziche' Zend_Mail. Risultato: codice inutile, piu' lento e maggiormente esposto alla possibilita' di bug.
Per rispondere invece a kiuz riguardo il commento (Oggetti > Eventi): uno non esclude l'altro e l'utilizzo degli eventi talvolta e' fondamentale per gestire con potenza ed eleganza situazioni complesse che altrimenti sarebbero gestibili in maniera veramente difficile.
Un esempio JS: hai il tuo sito con un quadrilione di pagine e ti interessa fare in modo che quando l'utente lascia una pagina vengano eseguiti alcuni metodi. Una soluzione elegante e' quella di avere un gestore di eventi nel qual puoi registrarli e farli eseguire nel momento in cui quel determinato evento capita, in questo caso il cambio di pagina. Questo approccio ti evita, per esempio, di non dover mettere in ogni pagina un pezzo di codice che implementi tutta questa logica.
Scusate per il megapippone :P

tra le altre cose mi piacerebbe vedere un server che gioca a pollicino o.o

Guarda, mi trovo d'accordo con te (in parte), la classe poteva benissimo ereditare la classe padre (anzichè istanziarla al suo interno) e fare l'verride di quelle due funzioni che servono (__construct e setBody) detto questo, però, è anche vero che una programmazione solamente procedurale complica la gestione e manutenzione, quindi deve esserci un gisuto compromesso che permette di usare l'una o l'altra forma.

Sabato c'è stata una ottima conferenza a Milano (faccio un pò di pubblicità all'UGI Alt.NET, ma la conferenza era verametne di buon livello e molto Alt), in cui durante uno speech sul DDD si è parlato anche del fatto ceh la OOP è un buon strumento se usato come è stato usato inizialmente, mentre ormai non è altro che un modo per dire "io programmo figo" il che non è assolutamente buono.

Detto questo ritengo che la OOP sia comunque un buon modo di programmare SE usato con la testa e con le potenzialità che questo offre e non solo perché "la moda vuole questo".

@jhl.verona; per la campagna di documentazione più che volentieri e che ne dite di un sprint doc :)

Per quanto mi riguarda cerco di spiegare quanto posso (quello che so) ma ci sono diversi problemi nel farlo:

1. Il tempo (sembra una banalità e/o una scusa, ma purtroppo non è così)
2. Il modo di spiegarsi. Per quanto scrivere renda il tutto chiaro non è affatto semplice per me riuscire a spiegare quello che vorrei, sia perchè ogniuno ha un suo processo mentale e quindi la mia spiegazione potrebbe essere contorta per altri, che perché servirebbe un enorme lavoro di revisione su quanto detto (e qui colpa mia, scrivo abbastanza di getto e di rado torno su quanto scritto).

Questo non tanto per giustificarmi ma per indicare quali possibili problemi ci sono nello scrivere documenti.. per non parlare poi delle persone che ritengono che non spiegare ad altri sia la cosa migliore perchè gli permette di mantenere la loro competitività (lasciamo perdere che è meglio).

Tornando sull'argomento della discussione (che ormai ho perso) io non butterei via OOP & c. ma cerchierei di capire in che casi può essere usato? Per esempio, le views sono strumenti decisamente basati su OOP, qualcuno li ritieni strumenti non usabili & gestibili?
Semplicemente sono realizzati come dovrebbe essere e sono scritti da persone che ne capiscono parecchio, quindi sono riusciti a realizzare uno strumento usabile.

mavimo wrote:

Guarda, mi trovo d'accordo con te (in parte), la classe poteva benissimo ereditare la classe padre (anzichè istanziarla al suo interno) e fare l'verride di quelle due funzioni che servono (__construct e setBody) detto questo, però, è anche vero che una programmazione solamente procedurale complica la gestione e manutenzione, quindi deve esserci un gisuto compromesso che permette di usare l'una o l'altra forma.

mavimo wrote:

Detto questo ritengo che la OOP sia comunque un buon modo di programmare SE usato con la testa e con le potenzialità che questo offre e non solo perché "la moda vuole questo".