Vtigercrm modificare il comportamento dei campi data

From Studiosg
Jump to navigationJump to search

Benvenuti nella pagina Wiki di Simone Giustetti.


Lingue: English - Italiano



Comportamento del Controllo datefield

Le date sono gestite mediante un apposito controllo calendario (datefield) in VtigerCRM. In fase di inserimento o modifica dei dati, il controllo suggerisce automaticamente la data del giorno corrente. La compilazione automatica, generalmente utile, può risultare fastidiosa in alcuni contesti: ad esempio maschere con molte date. Una maschera in cui siano presenti molti campi data costringerebbe l'utente a scorrerli tutti correggendo o rimuovendo i valori indesiderati. Ne consegue la necessità di modificare il comportamento standard del controllo in modo che suggerisca in automatico una data nulla. Il suggerimento dovrebbe comparire solo quando l'utente selezioni esplicitamente il controllo e non a prescindere. Nel prosieguo dell'articolo verrà esposto come modificare il comportamento standard per i controlli data in VtigerCRM versione 5.2.1.


Funzionamento Interno di VtigerCRM

In VtigerCRM il codice di elaborazione dei dati è separato da quello di presentazione degli stessi. Le informazioni vengono estratte dal database, i file di configurazione ed altre fonti, elaborate e infine passate a sezioni separate del codice, che si occupano della formattazione e scrittura delle pagine HTML. Tutte le pagine generate dal software sono basate su modelli predefiniti detti template. VtigerCRM utilizza Smarty come motore per i template. I template consistono in file di testo formattati secondo una sintassi specifica, simile ad HTML con l'aggiunta di variabili e cicli. I modelli sono reperibili in una apposita directory all'interno dell'albero di installazione di VtigerCRM: Smarty/templates. Di seguito è elencato il contenuto di tale directory:

  bash-4.1# ls -la ./Smarty
  total 64
  drwxr-xr-x  8 apache apache  4096 Nov 15  2010 .
  drwxr-xr-x 28 apache apache  4096 Sep  7 01:32 ..
  -rw-r--r--  1 apache apache 24389 Nov 15  2010 COPYING.lib
  drwxrwxr-x  2 apache apache  4096 May  5  2011 cache
  drwxr-xr-x  2 apache apache  4096 Nov 15  2010 configs
  drwxr-xr-x  4 apache apache  4096 Nov 15  2010 libs
  drwxr-xr-x  2 apache apache  4096 Nov 15  2010 misc
  drwxr-xr-x  8 apache apache  4096 Nov 15  2010 templates
  drwxrwxr-x  2 apache apache 12288 Sep 16 00:25 templates_c

La directory templates contiene il codice sorgente dei modelli di controlli, maschere e pagine.
La directory templates_c contiene una versione precompilata dei template pronta per l'uso da parte del motore del programma.

Il file Smarty/templates/EditViewUI.tpl contiene alcuni template utilizzati dalle maschere del programma in fase di inserimento / modifica dei dati.

Il file Smarty/templates/DetailView.tpl contiene i template per i controlli predefiniti suddivisi sulla base del modulo di appartenenza.

Il file include/utils/utils.php contiene la funzione get_textdateField che impone il formato / valore di default per i campi data.

Il file include/utils/CommonUtils.php contiene la funzione getNewDisplayDate() che assegna il valore della data corrente ad un campo data. La funzione ha lo scopo di inizializzare le variabili ed è pertanto lei a definire il comportamento di tutti i campi data in fase di inserimento o modifica dei dati.

La funzione getNewDisplayDate() viene utilizzata in altri file del programma:

  • include/utils/EditViewUtils.php
  • include/utils/utils.php
  • modules/Emails/Save.php
  • modules/com_vtiger_workflow/VTSimpleTemplate.inc

Il codice sorgente della funzione deve essere modificato in modo da alterare il comportamento standard dei controlli calendario utilizzati nei moduli del programma. Il fine della modifica è far si che i campi data vengano inizializzati con valore nullo anzichè la data corrente. Di seguito e' riportato il codice sorgente originale ed il codice a seguito della modifica apportata.

Codice Sorgente Originale

   /** This function returns the date in user specified format.
   * Takes no param, receives the date format from current user object
   */
   
   function getNewDisplayDate()
   {
      global $log;
      $log->debug("Entering getNewDisplayDate() method ...");
         $log->info("in getNewDisplayDate ");
   
      global $current_user;
      $dat_fmt = $current_user->date_format;
      if($dat_fmt == '')
         {
                  $dat_fmt = 'dd-mm-yyyy';
         }
      $display_date='';
      if($dat_fmt == 'dd-mm-yyyy')
      {
         $display_date = date('d-m-Y');
      }
      elseif($dat_fmt == 'mm-dd-yyyy')
      {
         $display_date = date('m-d-Y');
      }
      elseif($dat_fmt == 'yyyy-mm-dd')
      {
         $display_date = date('Y-m-d');
      }
         
      $log->debug("Exiting getNewDisplayDate method ...");
      return $display_date;
   }

Codice Sorgente Modificato

   /** This function returns the date in user specified format.
   * Takes no param, receives the date format from current user object
   */
   
   function getNewDisplayDate()  {
      global $log;
      $log->debug("Entering getNewDisplayDate() method ...");
      $log->info("in getNewDisplayDate ");
   
      $display_date='';
      $log->debug("Exiting getNewDisplayDate method ...");
      return $display_date;
   }

Modifica Solo per Moduli Specifici

Il cambiamento introdotto influenzerà il comportamento di tutti i moduli di VtigerCRM. Naturalmente potrebbe essere desiderabile una modifica meno invasiva. Potrebbe valere ad esempio la pena di modificare il comportamento dei controlli calendario per alcuni moduli specifici lasciando invece inalterato il resto del programma. Supponendo di voler limitare la modifica al modulo predefinito "Progetti" ed al modulo personalizzato "Polizze", il codice sorgente dovra' essere modificato come segue:

   /** This function returns the date in user specified format.
   * Takes no param, receives the date format from current user object
   */
   
   function getNewDisplayDate()  {
      global $log;
      $log->debug("Entering getNewDisplayDate() method ...");
      $log->info("in getNewDisplayDate ");
   
      $display_date='';
      $module_name = $_REQUEST['module'];
      switch($module_name)  {
      case "Policy":
         $display_date = '';
      break;
      case "Project":
         $display_date = '';
      break;
      default:
         global $current_user;
         $dat_fmt = $current_user->date_format;
         if($dat_fmt == '')  {
            $dat_fmt = 'dd-mm-yyyy';
         }
         if($dat_fmt == 'dd-mm-yyyy')  {
            $display_date = date('d-m-Y');
         }  elseif($dat_fmt == 'mm-dd-yyyy')  {
            $display_date = date('m-d-Y');
         }  elseif($dat_fmt == 'yyyy-mm-dd')  {
            $display_date = date('Y-m-d');
         }
      }
      $log->debug("Exiting getNewDisplayDate method ...");
      return $display_date;
   }

La riga:

       $module_name = $_REQUEST['module'];

salva in una variabile locale il nome del modulo interessato, che verrà utilizzato in un apposito filtro. Il costrutto "case" consente di filtrare i moduli applicando codice specifico per ognuno di essi. In particolare le righe

      case "Policy":
         $display_date = '';
      break;
      case "Project":
         $display_date = '';
      break;

impongono un valore nullo in fase di inserimento e modifica dei campi data per i moduli "Polizze" e "Progetti". Infine le righe

      default:
         global $current_user;
         $dat_fmt = $current_user->date_format;
         if($dat_fmt == '')  {
            $dat_fmt = 'dd-mm-yyyy';
         }
         if($dat_fmt == 'dd-mm-yyyy')  {
            $display_date = date('d-m-Y');
         }  elseif($dat_fmt == 'mm-dd-yyyy')  {
            $display_date = date('m-d-Y');
         }  elseif($dat_fmt == 'yyyy-mm-dd')  {
            $display_date = date('Y-m-d');
         }
      }

specificano che venga applicato il comportamento standard del controllo calendario in tutti gli altri moduli di VtigerCRM.

L'esempio presentato è semplice, ma il codice può essere modificato ed ampliato ulteriormente per eseguire controlli sui valori suggeriti, imporre un comportamento specifico per ogni modulo oppure eseguire ulteriori elaborazioni sui dati. Può essere considerato una base di partenza generica.


Per commenti, consigli, domande inviate una e-mail all'indirizzo studiosg [chiocciola] giustetti [punto] net.



Lingue: English - Italiano