mavimo

Come potremmo rappresentare il ciclo di sviluppo di un software? Andando con ordine avremmo, inizialmente l'analisi delle richieste, la fase di progettazione, la fase di implementazione, di test e infine il rilascio. Completato questi passaggi si passa alle fasi successive (aggiunta di funzionalità) che sono praticamente identiche (non per nulla si chiama ciclo).

Vedremo ora come andare ad effettuare delle analisi di test su un applicativo (web based). Metto subito le mani avanti dicendo che applicativi differenti hanno necessità differenti di risposta e quindi non necessariamente un test su di un certo applicativo è significativo per un altro o che i risultati su di un progetto siano comparabili con quelli di un altro. Facciamo un esempio: immaginiamoci un software che fornisca i risultati della ricerca in un archivio, questo ha dei di tempi di risposta di circa 200ms.

E' un buon risultato? La risposta corretta è...

1. Alzi la mano chi non ha mai usato views.
2. Alzi la mano che l'ha mai usato.

Ok, non proprio tutti ma buona parte di voi ha alzato la mano, questo perchè è sicuramente uno strumento potentissimo per la visualizzazione delle informazioni, quindi è fondamentale (o comunque molto utile) andare ad integrare i propri moduli con views, permettendo così la massima facilità di utilizzo successiva.

Vediamo ora come andare ad integrare delle tabelle del nostro modulo in modo che siano collegate a views.

A chi capita di realizzare moduli o profili di installazione per Drupal può capitar di dover andare ad appoggiarsi ad altri moduli, uno di quelli che mi capita spesso di utilizzare è il moduli imagecache, utilissimo nella gestione delle immaginidata l'ampia possibilità che fornisce.

Fortunatamente mette a disposizione una interfaccia utente (Imagecache UI) ottima che permette di creare dei preset (delle impostazione di visualizzazione delle immagini) in pochi passaggi ed in un modo pulito, ma nel caso in cui questi preset debbano essere creati da un modulo o da un profilo di installazione? Vediamo come crearli da codice.

Dopo la pubblicazione del precedente articolo sull'autocompletamento in gedit, grazie ai consigli ricevuti da numerose parti, ho portato avanti alcune correzioni e ampliamenti delle funzionalità di autocompletamento, e sopratutto ho creato un nuovo tipo di liguaggio di scripting definito in gedit, in modo da non mischiare queste impostazioni con quelle predefinite di PHP come era precedentemente.

Spesso capita di dover sviluppare moduli o andare a personalizzare alcuni di questi e di necessitare di un sito di sviluppo per fare in modo che questo possa essere testato a dovere, o ancora che serva un sito con una serie di contenuti per vedere come si comporta Drupal in determinate occasioni.

Le strade percorribili sono molteplici, si va dalla creazione di un sito di sviluppo e poi una copia del database con tutte le impostazioni, a tecniche più avanzate che permettono customizzazioni più spinte.

Data la mancanza di documentazione in questo campo e le continue richieste da parte degli utenti di avere una guida per la realizzazione di un tema, più o meno complesso, per Drupal, ho iniziato a scrivere questa guida, che non pretende di essere completa ne troppo approfondita, ma spero che serva come base di partenza per tutti coloro che hanno intenzione di creare un proprio tema o cercare di capire come questo avviene.