Difference between revisions of "Default sound card"

From Studiosg
Jump to navigationJump to search
(Links updates mostly)
(Aggiornato i collegamenti, apportato qualche correzione minore ed abilitato il syntax highlight)
Line 1: Line 1:
−
Welcome to Simone Giustetti's wiki pages.
+
Benvenuti nella pagina Wiki di Simone Giustetti.
  
  
−
Languages: '''English''' - [[scheda_sonora_di_default | Italiano]]
+
Lingue: [[vtigercrm_update_date_field_default_behavior | 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 proseguo dell'articolo verrà esposto come modificare il comportamento standard per i controlli data in '''VtigerCRM versione 5.2.1'''.
  
−
I recently upgraded my "work" machine to Slackware 14.0 from a previously in use 13.37 release, that started to be too old for my needs. The upgrade procedure was easy and straightforward: in a couple of hours I could reboot to the new system. Unfortunately I noticed some annoying issues with the sound card later while configuring it. In the following article I'll discuss the issues and the corresponding solution.
 
  
 +
== 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.<BR>
 +
La directory '''templates_c''' contiene una versione precompilata dei template pronta per l'uso da parte del motore del programma.
  
−
While configuring the audio subsystem, the 3.2.29 kernel detected two sound cards instead of the only one the previously in use 2.6.37 kernel did. The newly detected card was set as default for the operating system but did not seem to work. Some annoying issues with the installed multimedia applications arose:
+
Il file '''Smarty/templates/EditViewUI.tpl''' contiene alcuni template utilizzati dalle maschere del programma in fase di inserimento / modifica dei dati.
−
* It was difficult / nearly impossible to set a decent volume level for some programs.
 
−
* The mixer volume controlling device needed to be selected after each reboot.
 
−
* '''No more than one multimedia application at a time seemed able to access the mixer'''. The earlier run one exclusively seized  mixers and sound cards preventing others from reproducing any sound.
 
−
* Sound related error messages appeared uninterruptedly.
 
−
* It was '''impossible to reproduce sound files or clips with Wine'''.
 
−
The situation was unbearable. Reverting to Slackware 13.37 was not an option so I decided to try and solve the configuration issues.
 
  
 +
Il file '''Smarty/templates/DetailView.tpl''' contiene i template per i controlli predefiniti suddivisi sulla base del modulo di appartenenza.
  
−
== Problem-solving  ==
+
Il file '''include/utils/utils.php''' contiene la funzione '''get_textdateField''' che impone il formato / valore di default per i campi data.
−
My first goal consisted in understanding why the 3.2.29 kernel was detecting two sound cards in a machine with only one. I started by reading the pseudo-file '''/proc/asound/cards''':
 
−
  root@darkstar_5:~# '''cat''' /proc/asound/cards
 
−
    0 [Generic        ]: HDA-Intel - HD-Audio Generic
 
−
                        HD-Audio Generic at 0xfeb44000 irq 42
 
−
    1 [Generic_1      ]: HDA-Intel - HD-Audio Generic
 
−
                        HD-Audio Generic at 0xfeb40000 irq 16
 
−
Then I read the device configuration for both cards from the output produced by command '''amixer'''. Each card was selected using the '''-c''' option:
 
−
  root@darkstar_5:~# '''amixer info''' ''-c'' 0
 
−
  Card default 'Generic'/'HD-Audio Generic at 0xfeb44000 irq 42'
 
−
    Mixer name    : 'ATI R6xx HDMI'
 
−
    Components    : 'HDA:1002aa01,00aa0100,00100200'
 
−
    Controls      : 5
 
−
    Simple ctrls  : 1
 
−
  root@darkstar_5:~# '''amixer info''' ''-c'' 1
 
−
  Card hw:1 'Generic_1'/'HD-Audio Generic at 0xfeb40000 irq 16'
 
−
    Mixer name    : 'Realtek ALC269VB'
 
−
    Components    : 'HDA:10ec0269,144dc608,00100100'
 
−
    Controls      : 17
 
−
    Simple ctrls  : 11
 
−
I thus learned that the second detected sound card was not a real device but the '''ATI video card [http://en.wikipedia.org/wiki/Hdmi HDMI] output device''' instead. Support for HDMI was introduced in kernel release 3.2 that explained why Slackware 13.37 had no issue with the ATI card: The 2.6 kernel could not manage the hardware anyhow.
 
  
 +
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 &egrave; pertanto lei ''a definire il comportamento di tutti i campi data in fase di inserimento o modifica dei dati''.
  
−
== Solutions ==
+
La funzione '''getNewDisplayDate()''' viene utilizzata in altri file del programma:
−
With the problem cause discovered two tentative solutions were possible:
+
* '''include/utils/EditViewUtils.php'''
−
# Disable the HDMI device in order for the operating system to ignore it.
+
* '''include/utils/utils.php'''
−
# Set the Realtek card as the default one for the system.
+
* '''modules/Emails/Save.php'''
 +
* '''modules/com_vtiger_workflow/VTSimpleTemplate.inc'''
  
−
I chose the former path given that I do not usually connect external devices to the video card anyway. The idea consisted in disabling the HDMI related kernel module by adding a '''blacklist''' entry in the '''/etc/modprobe.d/alsa-base.conf''' file. I needed the module name and in order to obtain it run command '''lspci''' using option '''-v'''. A synthesis of the output I got follows:
+
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 &egrave; far si che i campi data vengano inizializzati con valore nullo anzich&egrave; la data corrente. Di seguito e' riportato il codice sorgente originale ed il codice a seguito della modifica apportata.
−
  root@darkstar_5:~# lspci -v
 
−
  ...
 
−
  00:01.1 Audio device: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series]
 
−
          Subsystem: Advanced Micro Devices [AMD] nee ATI BeaverCreek HDMI Audio [Radeon HD 6500D and 6400G-6600G series]
 
−
          Flags: bus master, fast devsel, latency 0, IRQ 42
 
−
          Memory at feb44000 (32-bit, non-prefetchable) [size=16K]
 
−
          Capabilities: [50] Power Management version 3
 
−
          Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00
 
−
          Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 
−
          Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
 
−
          '''Kernel driver in use: snd_hda_intel'''
 
−
  ...
 
−
  00:14.2 Audio device: Advanced Micro Devices [AMD] Hudson Azalia Controller (rev 01)
 
−
          Subsystem: Samsung Electronics Co Ltd Device c608
 
−
          Flags: bus master, slow devsel, latency 32, IRQ 16
 
−
          Memory at feb40000 (64-bit, non-prefetchable) [size=16K]
 
−
          Capabilities: [50] Power Management version 2
 
−
          '''Kernel driver in use: snd_hda_intel'''
 
−
Both cards needed the same module. Blacklisting snd_hda_intel module was impossible: the latter solution, '''configuring the Realtek card as default''', seemed the only feasible one.
 
  
 +
=== Codice Sorgente Originale ===
 +
<syntaxhighlight lang="php">
 +
  /** 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;
 +
  }
 +
</syntaxhighlight>
  
−
The installed [http://www.alsa-project.org/main/index.php/Main_Page ALSA] library version, 1.0.26, can work without any configuration files, by directly interfacing to the system. To bypass the system configuration and impose a customized one the configuration files are needed. For this particular case I created file '''/etc/asound.conf''' aimed at configuring sound cards for the whole system. The file affects audio subsystem configuration for all users. The following entries were added to the file:
+
=== Codice Sorgente Modificato ===
−
   root@darkstar_5:~# '''cat''' /etc/asound.conf
+
<syntaxhighlight lang="php">
−
   # Set the realtek sound card as the default one
+
   /** This function returns the date in user specified format.
−
   defaults.ctl.card 1
+
   * Takes no param, receives the date format from current user object
−
   defaults.pcm.card 1
+
   */
−
   defaults.pcm.device 0
+
    
−
To check the configuration update I restarted ALSA:
+
   function getNewDisplayDate()  {
−
  root@darkstar_5:~# '''/etc/rc.d/rc.alsa restart'''
+
      global $log;
−
  Loading ALSA mixer settings:  /usr/sbin/alsactl restore
+
      $log->debug("Entering getNewDisplayDate() method ...");
−
  Found hardware: "HDA-Intel" "Realtek ALC269VB" "HDA:10ec0269,144dc608,00100100" "0x144d" "0xc608"
+
      $log->info("in getNewDisplayDate ");
−
   Hardware is initialized using a generic method
+
    
−
And was immediately able to verify it complied with my wishes:
+
      $display_date='';
−
  root@darkstar_5:~# '''amixer info''' ''-c'' 0
+
      $log->debug("Exiting getNewDisplayDate method ...");
−
  Card hw:0 'Generic'/'HD-Audio Generic at 0xfeb44000 irq 42'
+
      return $display_date;
−
    Mixer name    : 'ATI R6xx HDMI'
+
   }
−
    Components    : 'HDA:1002aa01,00aa0100,00100200'
+
</syntaxhighlight>
−
    Controls      : 5
 
−
    Simple ctrls  : 1
 
−
  root@darkstar_5:~# '''amixer info''' ''-c'' 1
 
−
  Card hw:1 'Generic_1'/'HD-Audio Generic at 0xfeb40000 irq 16'
 
−
    Mixer name    : 'Realtek ALC269VB'
 
−
    Components    : 'HDA:10ec0269,144dc608,00100100'
 
−
    Controls      : 17
 
−
    Simple ctrls  : 11
 
−
  root@darkstar_5:~# '''amixer info''' ''-d'' default
 
−
  Card default 'Generic_1'/'HD-Audio Generic at 0xfeb40000 irq 16'
 
−
    Mixer name    : 'Realtek ALC269VB'
 
−
    Components    : 'HDA:10ec0269,144dc608,00100100'
 
−
    Controls      : 17
 
−
    Simple ctrls  : 11
 
−
To double check I started a test sound file reproduction by running the '''aplay''' command. The "default" output card was selected using the '''-D''' option:
 
−
   root@darkstar_5:~# '''aplay''' ''-D'' default /usr/share/sounds/alsa/Front_Center.wav
 
−
  Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
 
−
Both speakers reproduced the "front center" words sequence when previously I managed to get only an annoying silence.
 
  
 +
=== Modifica Solo per Moduli Specifici ===
 +
Il cambiamento introdotto influenzer&agrave; 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:
 +
<syntaxhighlight lang="php">
 +
  /** 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;
 +
  }
 +
</syntaxhighlight>
  
−
For any feedback, questions, errors and such, please e-mail me at ''studiosg [at] giustetti [dot] net''
+
La riga:
 +
<syntaxhighlight lang="php">
 +
      $module_name = $_REQUEST['module'];
 +
</syntaxhighlight>
  
 +
salva in una variabile locale il nome del modulo interessato, che verr&agrave; utilizzato in un apposito filtro. Il costrutto "case" consente di filtrare i moduli applicando codice specifico per ognuno di essi. In particolare le righe
 +
<syntaxhighlight lang="php">
 +
      case "Policy":
 +
        $display_date = '';
 +
      break;
 +
      case "Project":
 +
        $display_date = '';
 +
      break;
 +
</syntaxhighlight>
  
−
External links
+
impongono un valore nullo in fase di inserimento e modifica dei campi data per i moduli "Polizze" e "Progetti". Infine le righe
 +
<syntaxhighlight lang="php">
 +
      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');
 +
        }
 +
      }
 +
</syntaxhighlight>
  
−
----
+
specificano che venga applicato il comportamento standard del controllo calendario in tutti gli altri moduli di VtigerCRM.
 +
 
 +
L'esempio presentato &egrave; semplice, ma il codice pu&ograve; 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&ograve; essere considerato una base di partenza generica.
 +
 
 +
 
 +
Per commenti, consigli, domande inviate una e-mail all'indirizzo studiosg [chiocciola] giustetti [punto] net.
  
−
* [http://www.alsa-project.org/main/index.php/Documentation The ALSA project documentation page]
 
−
* [https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture The ALSA related page in the ArchLinux WIKI]
 
  
 
----
 
----
  
−
Languages: '''English''' - [[scheda_sonora_di_default | Italiano]]
+
Lingue: [[vtigercrm_update_date_field_default_behavior | English]] - '''Italiano'''

Revision as of 22:06, 23 December 2015

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 proseguo 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

Retrieved from "http://www.giustetti.net/wiki/index.php?title=Default_sound_card&oldid=534"