Le migliori pratiche per i nomi delle variabili dei moduli personalizzati?


8

Ho preso l'abitudine di creare pannelli di configurazione abbastanza robusti per i miei moduli ora e trovo che i nomi delle variabili e la gestione siano abbastanza dolorosi .

Ho variabili come mymodule_section_subvar_varname_type_contexte non solo perdo traccia dell'ordine degli elementi nei miei nomi di variabili, ma mi sento come se avere un nome di variabile che è lungo un difetto di progettazione.

Ho preso in considerazione l'utilizzo di un array serializzato in una variabile mymodule_section_settingsinsieme a una serie di funzioni che semplificano il mantenimento di tale array, ma mi piacerebbe un po 'di input in quali (se presenti) best practice sono state stabilite al di fuori dei prefissi e / o esempi di moduli di cui ci fidiamo e cosa stanno facendo per grandi insiemi di variabili.

Grazie!


Inoltre, vorrei prendere in considerazione gli aggiornamenti anche in questo (motivo per cui mi sto appoggiando a un array serializzato), quindi apportare modifiche ai nomi delle variabili non rende i dati orfani e aggiungere ulteriore lavoro per funzionalità / test del percorso di aggiornamento aggiuntivi
electblake

Risposte:


7

È possibile utilizzare una variabile Drupal per contenere un array; questo è ciò che fanno anche i moduli core di Drupal (vedi book_type_is_allowed () ).

È possibile utilizzare una singola variabile Drupal per contenere diverse impostazioni utilizzate da un modulo in un array. Con l' #treeattributo form è ancora possibile usare system_settings_form () per salvare l'array in una variabile Drupal senza scrivere alcun codice aggiuntivo. La serializzazione della deserializzazione del codice viene eseguita automaticamente dalle funzioni principali di Drupal che gestiscono le variabili Drupal (vedere il codice di variabile_set () ).

La domanda è quindi: quando una singola variabile Drupal dovrebbe essere usata per contenere impostazioni diverse? Vorrei utilizzare una singola variabile per le impostazioni utilizzate da una funzione o un gruppo di funzioni; se l'array contiene valori usati da (ad esempio) 10 funzioni diverse, ma tali funzioni accedono a un singolo valore (o un paio di valori) da quell'array, allora non userei una singola variabile persistente per le impostazioni.


Sai tu / qualcuno come reagirà questo tipo di scenario all'interno di Features e / o Strongarm? Odierei bloccare quei moduli e gli utenti che apprezzano la mobilità che questi moduli possono offrire.
electblake,

Non vedo alcun motivo per cui Feature avrebbe qualche problema con una variabile Drupal che contiene un array. Qualcun altro potrebbe segnalarti in dettaglio se è completamente vero o no.
kiamlaluno

sì, capisco che questo potrebbe essere un po 'fuori dalla portata di questa domanda - ma voglio assicurarmi che questo standard funzioni per tutti :) Riporterò una relazione dopo aver provato alcune cose.
electblake,

2

Se sono correlate una serie di impostazioni, è logico inserirle in un array. Ad esempio se lo stai facendo in several variable_getsequenza. Ti dà una certa flessibilità oltre ad essere potenzialmente un po 'più veloce.

Tuttavia, ciò renderà difficile per altri programmi modificare le impostazioni manualmente tramite qualcosa come drush vset o strongarm. In questi casi i nomi di variabili lunghe possono effettivamente essere utili.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.