sfondo

Tra un anno i miei clienti porteranno a Drupal un servizio di portale intranet relativamente complesso (pianificazione, monitoraggio e reportistica effettivi e altro) perché lo dice la sede centrale. Sono stati fatti pochissimi sforzi per determinare se questa è la scelta tecnica giusta ed è al di fuori del controllo dei miei clienti o persino dei loro capi.

L'attuale portale è un abominio in fase di re-factoring e credo che il piano più conveniente sarà quello di introdurre un livello del modello di dominio tramite Doctrine 2 e inserire nei modelli il 99,9% di tutte le logiche di validazione aziendale e di input , eliminando l'abominio fino a quando non è una vista scheletrica e un livello logico di autenticazione.

Domanda

Per qualsiasi specialista di Drupal là fuori, sembra un approccio praticabile? Doctrine2 potrebbe funzionare bene con Drupal o la logica di livello superiore di Drupal necessita di un'integrazione molto più stretta con i dati?

Abbiamo realizzato alcuni siti in cui abbiamo collegato sistemi esterni a Drupal in cui i dati dovevano essere conservati nel sistema esterno. Questo è ciò con cui passo la maggior parte del mio tempo a lavorare.

Quando lo facciamo, in genere creiamo un tipo di contenuto per "stub" il contenuto nell'altro sistema. Il tipo di contenuto contiene solo il titolo del nodo e un campo CCK per l'identificatore univoco nell'altro sistema. Insieme a questo ci sono molte funzioni hook_nodeapi . Ad esempio, l' loadhook chiamerà il sistema remoto e aggiungerà i dati al nodo. È inoltre necessario escogitare un metodo per ottenere i dati esterni nei risultati di ricerca. Ci sono alcuni metodi per questo, ma quelli sono troppo lunghi per entrare qui.

Mentre ci sono alcuni aspetti negativi, troviamo che funziona bene e consente cose normali di Drupal come commenti, tag, ecc.

L'unica cosa sensata da fare, data la linea del tempo, è costruirla in Drupal 7. Una delle caratteristiche più importanti di Drupal 7, sono entità, DBNTG e campi.

Una rapida panoramica

• Le entità sono un modo per definire una struttura di dati. Esempi di entità integrate in Drupal sono, nodi (contenuto principale), utenti, termini di tassonomia.
• Fields è qualcosa che può essere collegato a un'entità, che contiene anche dati. L'uso dei campi ha il vantaggio di avere un solo posto per gestire i dati e possono essere estesi in vari modi. Un esempio di un campo potrebbe essere un allegato di file o un riferimento a un'altra entità.
• DBTNG (Database la prossima generazione) è ciò che la comunità Drupal aveva chiamato in codice il nuovo livello di astrazione del database. Prima di questo, eseguivamo query con segnaposto (che è ancora supportato), ma ora la maggior parte delle query sono costruite con classe. Un motivo di ciò è anche che i campi ottengono le loro tabelle di database create in base alle impostazioni. Questo aiuta a creare codice che funzionerà, anche se i campi vengono creati con impostazioni diverse.

Queste sono solo alcune delle funzionalità, ma ciò significa che, a meno che tu non voglia creare un abominio di Drupal, dovresti iniziare a pensare a come funziona Drupal e usarlo invece di provare a far funzionare Drupal in un modo non progettato.

Poiché Drupal è PHP, è possibile creare moduli personalizzati e utilizzare Doctrine2 per fare ciò che si desidera. Ma suppongo che finirai con un sito che ha molto poco in comune con la maggior parte dei siti Drupal.

Questa è una domanda piuttosto ampia, quindi fornirò una risposta di alto livello, se hai domande più specifiche ti preghiamo di farle come domande separate.

Suggerirei di mappare il più possibile la struttura del sito attuale. Che tipo di cose fa, quali flussi di lavoro ci sono. Qual è il contenuto quali sono gli utenti.

I tipi di contenuto sono un modo pratico di dividere il contenuto. Anche l'abominio avrebbe avuto tipi I cosa (avrei sperato) che si associano agli URL.

Dopo aver determinato i tipi di contenuto, puoi guardare alla migrazione del contenuto nel tuo nuovo sito. Quindi puoi guardare cose come flussi di lavoro, pianificazioni, utenti, ecc.

Preferirei spostarmi all'ingrosso. Avere il contenuto gestito da più di un sistema è un enorme mal di testa tecnico. E raddoppia lo sforzo di manutenzione.

Una cosa che direi è che può valere la pena assumere qualcuno per farlo. Ci sono state alcune migrazioni Drupal di grande successo con enormi set di dati. Ma se non hai esperienza in Drupal potresti fare diversi passi sbagliati e costare molto tempo. (Posso consigliare personalmente cyrve , non ho affiliazioni attuali con loro)