Sviluppo template troppo invasivo

[g4b0]

Ciao a tutti,
Ho deciso di scrivere qui perché mi sembra piú una "discussione generale" piuttosto che un singolo problema di implementazione.

Non trovate che lo sviluppo dei template sia troppo invasivo? Mi spiego meglio: se voglio scrivere un template devo modificare molti moduli, anche solo per aggiungere i nuovi hook, perdendo in questo modo la compatibilitá per eventuali aggiornamenti (anche di sicurezza).
Sto sviluppando per Drupal oltre che su Prestashop, e devo dire che da questo punto di vista c'é veramente un abisso.

Secondo me sarebbe necessario modificare questo comportamento, introducendo una maggiore separazione tra moduli e template. A vostro avviso ha senso intavolare una discussione su un eventuale crescita di Prestashop in questa direzione? Sarebbe forse meglio usare qualche altra sezione del forum?

[disarci]

Personalmente no,
ritengo che in generale gli hook non siano MAI sufficienti, anche se raramente ho dovuto aggiungerne,
finora non ho mai dovuto mettere mano al codice php per creare dei temi.

Tieni presente che i moduli sono uno strumento utile proprio per questo, e che tutti i moduli "realizzati decentemente" hanno la possibilità di sovrascrivere il tpl nel tema, quindi "senza" modificarli.

E comunque dare ad un cliente un pacchetto con n. moduli e un tema fa parte degli standard di prestashop.
E la gestione di smarty aiuta a cambiare molto di prestashop senza dover modificare una riga di php (quindi mantenendo la compatibilità con aggiornamenti etc).

Ritengo interessante la discussione, chi ha fatto esperienze in temi "complessi" scriva le sue opinioni.

[g4b0]

Tieni presente che i moduli sono uno strumento utile proprio per questo, e che tutti i moduli “realizzati decentemente” hanno la possibilità di sovrascrivere il tpl nel tema, quindi “senza” modificarli.

Ti porto un esempio che ci ha fatti impazzire di recente relativo un modulo presente di default in presta: homefeatured. Detto modulo prepara per smarty un array chiamato products, e chiama il tpl. Tale tpl é presente all'interno del modulo e non viene ricercato nel template.

function hookHome($params)
   {
       global $smarty;

       $category = new Category(1);
       $nb = intval(Configuration::get('HOME_FEATURED_NBR'));
       $products = $category->getProducts(intval($params['cookie']->id_lang), 1, ($nb ? $nb : 10));
       $smarty->assign(array('products' => $products, 'homeSize' => Image::getSize('home')));

       return $this->display(__FILE__, 'homefeatured.tpl');
   }

Modificando il template il mio collega designer ha dovuto aggiungere un hook per visualizzarlo in modo differente e per richiamare il relativo tpl all'interno del template, ed ha creato la funzione hookHomeNomesito().

Tutto pare funzionare alla grande finché non ci accorgiamo che il carrello non visualizza piú i prodotti. Dopo ore di debug ho scoperto che nel file order.php (quello responsabile, tra le altre cose, di visualizzare il carrello) viene inizializzato per smarti un array che, guarda un po', si chiama products. Ho modificato a mano il modulo cambiando il nome dell'array e tutto é tornato a funzionare.

Secondo me ci sono alcuni errori concettuali in tutto questo:

1) Il designer dovrebbe lavorare solamente sui file tpl, scordandosi di tutto quello che é php, invece in questo caso é stato costretto a farlo.
2) Le variabili e le funzioni dichiarate dentro un modulo dovrebbero essere precedute da un prefisso, ad esempio nomemodulo_
3) Ci vorrebbe un metodo piú pulito per separare la logica applicativa dal design

Tutto questo in teoria. In pratica sono anche disposto a "sporcarmi le mani con i bit", ma prima di scrivere codice mi piacerebbe intavolare una bella discussione, magari valutando le soluzioni scelte da Drupal che IMHO é un gran CMS (ma per un ecommerce ci vuole presta )

[Giuseppe T]

Per abisso intendi che è meglio chi?

[g4b0]

Sicuramente Drupal. Ma con questo non intendo dire che presta non sia un buon prodotto, anzi... Altrimenti non sarei qui a discutere ed a proporre cambiamenti!

Dal punto di vista del modello MVC Drupal é avanti anni luce, forse anche per la comunitá decisamente piú ampia e per il target piú generico che si propone. Ció non toglie che peró presta debba crescere dal punto di vista della qualitá del codice, se vuole diventare il punto di riferimento per l'ecommerce (come lo é Drupal per il CMS/CMF ad ampio raggio).

Un gran problema di presta legato a ció di cui si discute, per esempio, sono gli aggiornamenti: se io installo un tema "invasivo", che mi modifica moduli del core, perdo la compatibilitá con eventuali futuri aggiornamenti di sicurezza, e sono costretto a patchare il codice a mano. Io lo faccio, ma il non programmatore, o il programmatore alle prime armi non lo fa, ed il risultato sará la percezione che presta é un software non sicuro (ovviamente quando inizierá ad essere bucato per via dei non-aggiornamenti). E per un ecommerce la percezione di sicurezza tutto o quasi... poi vengono le stelline che piovono nei carrelli