Drupal Architettura ~ Una visione architettonica

Abbiamo parlato di relazioni tra componenti, ma dobbiamo anche notare l'organizzazione degli stessi.

Ottenere un sistema semplice che permette la localizzazione di componenti e di facile integrazione in un ambiente di tale componente o funzionalità, che collega una serie di componenti è un credito di buona architettura.

Non c'è dubbio che a livello strutturale di un sistema di collegamenti simbolici agevolare questo lavoro.

Discutiamo di sotto della struttura consigliatoVector SF e altri partner per Red.es e che viene utilizzato sui server Brqx.

La struttura ha una misura di carattere inconfondibile in qualsiasi sistema. La parola iniziale "brqx" qualunque essa sia individuare, serve a due scopi:

1 .- Non essere confuso con una directory in cui installare tutti i sistemi (Unix, Mac, Windows).

2.- Non essere confuso con un piano preciso, non si è mai fatto tutti i piani che chiamano brqx.

La seconda stringa definisce il livello di parola:

- Base : Prodotto di livello (livello principale)

- Lnk : Livello di link (a livello di link)

- Proy : livello di progetto (in questo caso, l'inglese è diverso: livello di progetto)

- Pers : Personalizzazioni

- www : Il livello finale di siti (a livello di sito)

Il terzo termine della stringa definisce il prodotto. Partimos de Drupal, pero la estructura está pensada para adaptarse a cualquier producto. Si comincia con Drupal, ma la struttura è progettata per adattarsi a qualsiasi prodotto.

/brqx/base/drupal

La quarta parola definisce la versione del prodotto. Se antepone una letra debido a que muchos sistemas tienen problemas si una carpeta comienza por número. Si mette una lettera, perché molti sistemi hanno problemi se una cartella inizia con il numero.

- v50

- v60

- v70

Una volta selezionata la versione ha definito tre livelli:

- core ' Core invariable de Drupal

- modules ' Módulos de Drupal

- themes ' Temas de Drupal

Finora non abbiamo intenzione di approfondire ulteriormente nella struttura. Siamo solo andando a indicare un esempio di esso:

/core

/core/v612

/core/v615

…

/modules/abc/c/captcha/captcha_2_1

Parliamo ora del livello 2.

A questo livello indica i componenti che sono certificati e / o versioni finali in uso.

Il percorso iniziale è simile:

/brqx/lnk/drupal/v60/modules/abc/c/captcha

Qui si specifica il formato con nuclei funzionali i collegamenti (la versione già certificata).

Possiamo vedere il nucleo bas (modulo base) che definisce le funzionalità di base richieste per tutti i siti di architettura.

Il percorso di questa funzionalità comune è:

/brqx/proy/drupal/v60/base

I moduli che compongono:

a/ajax ' /brqx/lnk/drupal/v60/modules/abc/a/ajax

c/cck ' /brqx/lnk/drupal/v60/modules/abc/c/cck

...

Questa informazione è ormai obsoleto, ma sicuramente un modo per insegnare quando organizzano un approccio completo e complesso architettonico si applica a un sistema multi sviluppo del sito con una filosofia di semplicità.

Il vantaggio di utilizzare una struttura omogenea è che i processi possono essere automatizzati, la domanda quindi Drush così come la nostra architettura ci permette di scripting flessibilità nello sviluppo di fuori dei siti común.Aunque non è completamente aggiornato, questa architettura è scaricabile da internet:

Scripting Unix Brqx

Politiche Permetti agli script di un'agilità che non può essere ottenuta in un processo web. Drupal sa. Los drupaleros lo saben. Il Drupalers sapere.

Vi invito a imparare a creare gli script di shell per automatizzare i processi, personalizzare le impostazioni.

C'è così tanto da imparare che esalta il prodotto finale.

E 'indispensabile un corretto studio dei moduli necessari prima di decidere su ogni ulteriore sviluppo.

Si tratta di un portale multi trascendente come i moduli e componenti selezionati.

Sarà molto importante per la valutazione delle componenti comuni, non solo quelli forniti da Drupal, ma le categorie, viste, tipi di dati definiti per semplificare gli sviluppi futuri.

Per tutto questo, che un focus su architettura orientato ai componenti è una chiave per il successo del prodotto.

La tranquillità di sapere che questa funzionalità sia già stata definita dal componente X, per affrontare lo sviluppo come se fosse un grande Lego, per sapere quali parti sono disponibili e sono esempio diretto di come questi interagiscono pezzi.

Pertanto, l'approccio ad un portale dovrebbe essere una parte di architettura.

Non dobbiamo isolare lo sviluppo del portale per l'esecuzione di tutti i portali.

Quindi non ci saranno comuni componenti e componenti specifici per questo portale

Questi componenti possono essere fisico e logico.

I componenti fisici sono tutte fornite da Drupal quindi imputabile fisicamente, quali moduli, temi, template, ecc

E componenti logica generato dal prodotto da loro, come blocchi, punti di vista e gli stessi moduli, temi e modelli.

La buona architettura deve considerare gli elementi comuni a disposizione per minimizzare i successivi sviluppi e di unire gli sforzi nella lotta per la qualità del prodotto finale.

Pertanto, lo studio continuo dei moduli e la documentazione giornaliera di componenti selezionati e sviluppati è considerato fondamentale per l'architettura di successo è distribuito correttamente e godere dei benefici del prodotto.

Come potete vedere, questo metodo va oltre i componenti Drupal. Sea este un producto, pero la filosofía de control documental y del estudio del arte continuo de posibilidades de implementación es y será aplicable a cualesquiera productos que estén enfocados en modo de componentes, en modo bazar, como suele estar planteado siempre el software libre. Sia questo un prodotto, ma la filosofia del documentario e studio d'arte continua possibilità di attuazione e si applicano sia ai prodotti che si concentrano sulla modalità componente, bazar modo, come spesso formulata software sempre gratuito.

Come ottenere una serie di portali? ¿ Realmente creen que de un portal a otro hay tantas diferencias ? Pensi veramente che un portale verso un altro ci sono così tante differenze?

La realtà è che no, le loro somiglianze raramente inferiore al 90% dei componenti comuni utilizzati.

Pertanto, la necessità di preparare un architettura a componenti, che permette un facile utilizzo RE.

Questa architettura richiede un sistema completo di documentazione per aiutare a identificare e diagnosticare in modo più adeguato la soddisfazione dei requisiti.

Queste relazioni devono essere fatti per le funzionalità comuni.

Drupal ci permette di lavorare, come già proposto un proprio insieme di relazioni tra moduli, ma dobbiamo continuare lo stesso lavoro che l'organizzazione di molte altre componenti che produciamo.

Per stabilire una base iniziale, inserire la suddivisione proposta da Drupal.

Si è specificato un elenco delle caratteristiche più comuni della maggior parte dei siti web:

- Autenticazione

- Presentazione dei contenuti

- Comunità

- Gestione degli utenti

- Email - Liste - Forum

- Pubblicità - Popups

- Ubicazione

- Ricerca

- Syndication

La struttura della comunità Drupal moduli ancora in un set completo di funzionalità che si aggiungono alla più comuni. Se indican a continuación: In basso:

- Utilità

- Content Management

- Amministrazione

- Tipi di contenuto

- Sviluppo

- Comunità

- Media

- E-Commerce

- Filtros - Formato de entrada- Filtri - Ingresso formato

- Viste

- Categorie

- Mobilità

- Javascript Utilities

- Navigazione

- Gestione dei file

- Backup - Import - Export

- Paging

- Sicurezza

- Prevenire lo spam

- Valutazione - voto

- Localizzazione - Lingue

- Gruppi organici

- Statistiche

- Eventi e flussi di lavoro

- Performance

- Giochi

- RDF - Formati

- Gestione Tour

E 'una base per costruire un coerente e componenti con un semplice riutilizzo.

Le prime volte che si arriva a Drupal, non considerare la sua struttura come un luogo importante per gestire portali multipli.

gli sviluppatori di Drupal se stesso anche cominciare a orientare la possibilità e l'importanza di una buona architettura file.

Vedendo che è un grave errore mettere tutto in "moduli". La possibilità di qualificarsi in "sites / all / modules 'diversi approcci e diversi raggruppamenti di moduli.

Questa capacità di discernere i bisogni comuni di soluzioni specifiche per uno o altro portale è architettura.

E 'importante affrontare correttamente i portali che desiderano distribuire ed è importante per capire l'approccio raccomandato da Drupal libero e, se invece di cercare una sola guerra è offerta per una condivisione di conoscenze e competenze nello sviluppo.

Quello che abbiamo chiamato Metodologías Ágiles Colaborativas, dove il vostro successo dipende dal successo di altre società del clamoroso successo pieno del prodotto.

Seguendo questa filosofia, la gestione del portale non deve essere un controllo di versione, e quindi il prodotto stesso ha un proprio controllo di versione.

Le modifiche o miglioramenti devono essere coerenti e concordare con gli autori molto di questi moduli o temi. Es esta idea la que nos infunde Drupal, y además es la más adecuada para asegurar los criterios de calidad del software. E 'questa l'idea che ci dà Drupal, ed è meglio per assicurare che i criteri di software di qualità.

Quindi possiamo vedere la struttura ideale di gestione di portali che devono essere non di gestione delle versioni.

In questa struttura abbiamo una parte direttamente collegata al prodotto come ad esempio le cartelle:

-"includes"

-"scripts"

-"profiles"

-"modules"

-"misc"

-"themes"

Potrebbe essere una serie di collegamenti simbolici "che punta alla ultima versione stabile del prodotto.

Quindi in parte delegato file e più in generale i siti di personalizzazione del prodotto.

All'interno di file può costituire una struttura comune con le personalizzazioni per i documenti come icone, loghi e immagini:

/files/

Questo percorso può essere configurato per ottenere un accoppiamento ottimale dei componenti più comuni.

In linea di altri, nei siti seguente struttura hanno già fatto con Drupal

/sites/all/ --> Per tutti i siti

/sites/default/ --> Impostazione predefinita

Come lei ha detto questa struttura aumenta la complessità del sito e ci permette di concentrarsi sulla semplicità.

In una tale struttura avrebbe, per esempio tre siti:

sites/site1

sites/site2

sites/site2

sites/all

sites/default

Come si può vedere tutto ciò che è all'interno dei siti stessi.

Noi preferiamo vedere il prodotto più facilmente, in cui l'intera struttura è sempre simile a prescindere dal luogo e dove i cambiamenti ambientali sono completamente trasparenti per la struttura interna:

Nella nostra visione di noi:

sites/default --> Impostazioni solo

sites/all --> Componenti personalizzati comune

Questa struttura sarà comune a tutti i siti.

Siamo tutti partecipi della documentazione insufficiente nella maggior parte dei progetti. Excesiva, nada práctica, demasiado completa. Eccessiva, poco pratico, troppo completo.

L'obiettivo è di preparare un dossier più vicina alle esigenze del cliente, una documentazione Abstract dettagli inutili e avvicinarsi ai reali obiettivi di ciascun progetto.

Abbiamo un sistema che semplicemente può rappresentare quasi qualsiasi progetto web. Questa metodologia è parzialmente dettagliate sul nostro sito webMetodologías Ágiles.

Vogliamo ridurre al minimo tutti i documenti coinvolti in un progetto e trasformare il tradizionale sistema di documentazione in un sistema più agile reso pienamente operativo e documenti di un sistema di documentazione che fornisce tutte le informazioni che sostiene pienamente in categorie e elementi documentali di ogni progetto.

E 'il momento di dimenticare i documenti PDF, Word di innumerevoli pagine. Es el momento para enfocar adecuadamente las dudas y desplegar un sistema que permita agilizar las consultas, evitar redundancia y apostar por la filosofía de "documentos vivos". È il momento di affrontare adeguatamente i problemi e realizzare un sistema per semplificare il processo di consultazione, al fine di evitare la ridondanza e la scommessa sulla filosofia di "documenti viventi".

Questo ruolo è fondamentale per la buona architettura. Debemos analizar las necesidades de cada rol y preparar una documentación acorde a los mismos y envuelta en un sistema ágil, intuitivo y muy bien categorizado. Analizziamo le esigenze di ogni ruolo e per preparare i documenti secondo loro, e avvolto in un flessibile, intuitivo e ben categorizzato.

Pertanto, la definizione delle astrazioni necessarie per raggiungere questo obiettivo, sia in termini di contenuti e in termini di documentazione finale sarà un altro parametro da considerare in una architettura portale.