a0002
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:
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.
Ci sono molti fattori che possono impedire il riutilizzo di un componente. Desde motivos meramente estéticos, aspectos de funcionalidad, necesidad de innovación. Da motivi puramente estetici, aspetti funzionali, necessità di innovazione.
Arrivare a decidere se riutilizzare un componente di una libreria di componenti o di un modulo è fornito da una decisione di architettura..
E 'certamente un vantaggio che a tempo debito, allora avremo la possibilità di innovare, ma anche per il riutilizzo.
Senza un buon sistema senza un buon documentario e architettura, questa seconda opzione non sarebbe possibile.
A livello di moduli e di altra linea Drupal diretta delle azioni dovrebbe essere a cooperare, ma per il momento fino a quando ci standardizzare un system di entities that sharing consente alle aziende di riutilizzare stesso modo in cui i moduli vengono riutilizzati, must essere propria gerarchia interna di ogni singolo dipartimento che gestisce questi componenti di auto.
Certamente un buon corso di action per il futuro di Drupal è di aumentare la funzionalità dei moduli con i componenti più comuni, così come la Posizione modulo, perché sicuramente si creerà uno person or modulo named persone, consentendo deployment tutte le caratteristiche del singolo.
Causa di tale assenza, la creazione di singoli componenti, per noi, allora dobbiamo decidere se tutti i nostri siti lo deve usare o ci sono alcuni che avrebbe utilizzato solo alcune caratteristiche.
La gamma delle possibilità è infinita.
Abbiamo parlato di tante altre decisioni importanti di architettura che si concentrano sulla riuscita del progetto e il successo di uno dei componenti metodologia agile.
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.
Un'altra importante caratteristica del software libero è la sua grande capacità di cambiamento, miglioramento, nuove funzionalità.
Questa filosofia è così variante in breve tempo una buona soluzione diventa obsoleta.
E 'quindi importante per un architetto in Drupal per tenersi aggiornati su nuovi componenti, il loro adattamento alle versioni.
Conoscendo bene l'Update Status y el Upgrade Status loro portali.
Prevedere i problemi e quando agire, essere preparati per questo. Es importante probar nuevas funciones, probar contribuciones para el producto, informarse de las ventajas aportadas. È importante per testare le nuove funzioni, contributi alla prova del prodotto, conoscere le prestazioni erogate.
Sfoglia comparazione di prodotti, analisi di nuove funzionalità realizzate per essere in grado di decidere se la notizia è importante per migliorare il sito o è semplicemente un codice esteso che fornisce nuove funzionalità.
Drupal ha più di 5.000 moduli attualmente disponibili quattro versioni in ballo, più di 500 contributi, molte informazioni. Todo ello hace al producto completo y complejo. Tutto questo rende il prodotto completo e complesso.
Ci sono mille varianti e diversi modi di fare le cose, nulla ha di essere il migliore, ad eccezione di alcuni casi eccezionali.
Così una buona architettura debba essere concepito che Drupal continuo sforzo nella ricerca di nuovi componenti e gli aggiornamenti ai componenti già esistenti.
