Latar Belakang

Setahun dari sekarang klien saya akan mem-porting layanan portal intranet yang relatif kompleks (penjadwalan, pelacakan dan pelaporan aktual, dan banyak lagi) ke Drupal karena kantor pusat mengatakan demikian. Sangat sedikit upaya telah dilakukan untuk menentukan apakah ini pilihan teknis yang tepat dan itu di luar kendali klien saya atau bahkan bos mereka.

Portal saat ini adalah kekejian yang sedang dalam proses re-factored dan saya percaya rencana yang paling efektif adalah membawa lapisan model domain melalui Doctrine 2 dan memasukkan 99,9% dari semua logika validasi input bisnis ke dalam model , membasmi kekejian sampai itu adalah tampilan kerangka & logika logika otentikasi.

Pertanyaan

Untuk spesialis Drupal di luar sana, apakah ini tampak seperti pendekatan yang layak? Bisakah Doctrine2 bermain baik dengan Drupal atau apakah logika Drupal tingkat lebih tinggi memerlukan integrasi yang lebih ketat ke data?

Kami telah melakukan beberapa situs di mana kami telah menghubungkan sistem luar ke Drupal di mana data harus disimpan dalam sistem luar. Ini adalah apa yang saya habiskan sebagian besar waktu saya bekerja dengan.

Ketika kita melakukan ini, kita biasanya membuat tipe konten untuk "mematikan" konten di sistem lain. Jenis konten hanya berisi judul simpul dan bidang CCK untuk pengidentifikasi unik di sistem lain. Seiring dengan ini banyak fungsi hook_nodeapi . Sebagai contoh, loadhook akan memanggil sistem remote dan menambahkan data ke node. Anda juga perlu menyusun metode untuk memasukkan data luar ke dalam hasil pencarian. Ada beberapa metode untuk ini, tetapi terlalu panjang untuk masuk ke sini.

Meskipun ada beberapa kelemahan, kami menemukan ini berfungsi dengan baik dan memungkinkan hal-hal Drupal yang normal seperti komentar, tag, dll.

Satu-satunya hal yang masuk akal untuk dilakukan, mengingat garis waktu, adalah untuk membangun ini di Drupal 7. Salah satu fitur paling menonjol dari Drupal 7, adalah entitas, DBNTG dan bidang.

Gambaran singkat

• Entitas adalah cara mendefinisikan struktur data. Contoh entitas yang terintegrasi dengan Drupal adalah, node (konten utama), pengguna, istilah taksonomi.
• Fields adalah sesuatu yang bisa dilampirkan ke entitas, yang juga menyimpan data. Menggunakan bidang memiliki keuntungan hanya memiliki satu tempat untuk menangani data dan mereka dapat diperluas dengan berbagai cara. Contoh bidang bisa berupa lampiran file, atau referensi ke entitas lain.
• DBTNG (Basis data generasi berikutnya) adalah apa yang oleh komunitas Drupal diberi kode nama lapisan abstraksi basis data baru. Sebelumnya, kami dulu melakukan kueri dengan placeholder (yang masih didukung), tetapi sekarang sebagian besar kueri dibangun dengan kelas. Alasannya adalah karena bidang membuat tabel basis datanya dibuat berdasarkan pengaturan. Ini membantu menciptakan kode yang akan berfungsi, bahkan jika bidang dibuat dengan pengaturan yang berbeda.

Ini hanya beberapa fitur, tetapi ini berarti bahwa kecuali jika Anda ingin membuat kekejian Drupal, Anda harus mulai berpikir tentang cara kerja Drupal dan menggunakannya daripada mencoba membuat Drupal bekerja dengan cara yang tidak dirancang untuk itu.

Karena Drupal adalah PHP, Anda dapat membuat modul khusus dan menggunakan Doctrine2 untuk melakukan apa yang Anda inginkan. Tapi tebakan saya adalah bahwa Anda akan berakhir dengan situs yang memiliki sedikit kesamaan dengan sebagian besar situs Drupal.

Ini adalah pertanyaan yang cukup luas jadi saya akan memberikan jawaban tingkat tinggi, jika Anda memiliki pertanyaan yang lebih spesifik, silakan tanyakan sebagai pertanyaan terpisah.

Saya menyarankan agar Anda memetakan sebanyak mungkin struktur situs saat ini. Apa jenis hal yang dilakukannya, alur kerja apa yang ada di sana. Apa kontennya apa saja pengguna.

Jenis konten adalah cara praktis untuk membagi konten. Bahkan kekejian akan memiliki tipe I hal (saya harapkan) yang memetakan ke URL.

Setelah Anda menentukan jenis konten, Anda dapat melihat migrasi konten ke situs baru Anda. Kemudian Anda dapat melihat hal-hal seperti alur kerja, jadwal, pengguna, dll.

Saya lebih suka pindah grosir. Memiliki konten yang dikelola oleh lebih dari satu sistem adalah sakit kepala teknis yang sangat besar. Dan gandakan upaya pemeliharaan Anda.

Satu hal yang akan saya katakan adalah bahwa mungkin ada baiknya mempekerjakan seseorang untuk melakukannya. Ada beberapa migrasi Drupal yang sangat sukses dengan kumpulan data yang sangat besar. Tetapi jika Anda tidak berpengalaman dalam Drupal Anda dapat membuat beberapa langkah salah dan menghabiskan banyak waktu. (Saya pribadi dapat merekomendasikan cyrve , saya tidak memiliki afiliasi dengan mereka saat ini)