Lý lịch

Một năm nữa, khách hàng của tôi sẽ chuyển một dịch vụ cổng thông tin mạng nội bộ tương đối phức tạp (lên lịch, theo dõi và báo cáo thực tế, v.v.) cho Drupal vì trụ sở chính nói như vậy. Rất ít nỗ lực đã được thực hiện để xác định xem đây có phải là lựa chọn kỹ thuật phù hợp hay không và nó nằm ngoài tầm kiểm soát của khách hàng của tôi hoặc thậm chí là ông chủ của họ.

Cổng thông tin hiện tại là một sự ghê tởm đang trong quá trình tái cấu trúc và tôi tin rằng kế hoạch hiệu quả nhất về chi phí sẽ là đưa một lớp mô hình miền qua Doctrine 2 và đưa 99,9% tất cả logic xác thực đầu vào và kinh doanh vào các mô hình , đưa ra sự ghê tởm cho đến khi nó là lớp logic xác thực & khung xương.

Câu hỏi

Đối với bất kỳ chuyên gia Drupal ngoài kia, điều này có vẻ như là một cách tiếp cận khả thi? Liệu Doctrine2 có thể chơi tốt với Drupal hay logic cấp cao hơn của Drupal cần tích hợp chặt chẽ hơn nhiều với dữ liệu?

Chúng tôi đã thực hiện một vài trang web nơi chúng tôi đã kết nối các hệ thống bên ngoài với Drupal nơi dữ liệu phải được lưu giữ trong hệ thống bên ngoài. Đây là những gì tôi dành phần lớn thời gian làm việc với.

Khi chúng tôi thực hiện việc này, chúng tôi thường tạo một loại nội dung để "loại bỏ" nội dung trong hệ thống khác. Loại nội dung chỉ chứa tiêu đề nút và trường CCK cho mã định danh duy nhất trong hệ thống khác. Cùng với điều này là rất nhiều hàm hook_nodeapi . Ví dụ, loadhook sẽ gọi ra hệ thống từ xa và thêm dữ liệu vào nút. Bạn cũng cần nghĩ ra một phương pháp để lấy dữ liệu bên ngoài vào kết quả tìm kiếm. Có một vài phương pháp cho việc này, nhưng những phương pháp này quá dài để vào đây.

Mặc dù có một số nhược điểm, chúng tôi thấy điều này hoạt động tốt và cho phép các công cụ Drupal bình thường như nhận xét, thẻ, v.v.

Điều hợp lý duy nhất để làm, theo dòng thời gian, là xây dựng điều này trong Drupal 7. Một trong những tính năng nổi bật nhất của Drupal 7, là các thực thể, DBNTG và các trường.

Tổng quan nhanh

• Các thực thể là một cách xác định cấu trúc dữ liệu. Ví dụ về các thực thể được xây dựng với Drupal là, các nút (nội dung chính), người dùng, thuật ngữ phân loại.
• Các trường là một cái gì đó có thể được gắn vào một thực thể, cũng chứa dữ liệu. Sử dụng các trường có lợi thế là chỉ có một nơi để xử lý dữ liệu và chúng có thể được mở rộng theo nhiều cách khác nhau. Một ví dụ về trường có thể là tệp đính kèm hoặc tham chiếu đến thực thể khác.
• DBTNG (Cơ sở dữ liệu thế hệ tiếp theo) là những gì cộng đồng Drupal đã đặt tên mã là lớp trừu tượng cơ sở dữ liệu mới. Trước đây, chúng tôi thường thực hiện các truy vấn với trình giữ chỗ (vẫn được hỗ trợ), nhưng bây giờ hầu hết các truy vấn được xây dựng với lớp. Một lý do cho điều này cũng là các trường có (các) bảng cơ sở dữ liệu của họ được tạo dựa trên các cài đặt. Điều này giúp tạo mã sẽ hoạt động, ngay cả khi (các) trường được tạo với các cài đặt khác nhau.

Đây chỉ là một số tính năng, nhưng điều này có nghĩa là trừ khi bạn muốn tạo ra một sự ghê tởm Drupal, bạn nên bắt đầu suy nghĩ về cách thức hoạt động của Drupal và sử dụng nó thay vì cố gắng làm cho Drupal hoạt động theo cách nó được thiết kế.

Vì Drupal là PHP, bạn có thể tạo các mô-đun tùy chỉnh và sử dụng Doctrine2 để làm những gì bạn muốn. Nhưng tôi đoán là bạn sẽ kết thúc với một trang web có rất ít điểm chung với hầu hết các trang web Drupal.

Đây là một câu hỏi khá rộng vì vậy tôi sẽ đưa ra câu trả lời ở cấp độ cao, nếu bạn có câu hỏi cụ thể hơn, vui lòng hỏi chúng dưới dạng câu hỏi riêng biệt.

Tôi sẽ đề nghị bạn vạch ra càng nhiều càng tốt cấu trúc của trang web hiện tại. Những loại công việc nào nó làm, những gì quy trình công việc đang có. Nội dung người dùng là gì.

Các loại nội dung là một cách tiện dụng để phân chia nội dung. Ngay cả sự ghê tởm cũng sẽ có loại I điều (tôi đã hy vọng) ánh xạ tới URL.

Khi bạn đã xác định các loại nội dung thì bạn có thể xem xét di chuyển nội dung, đến trang web mới của bạn. Sau đó, bạn có thể xem xét những thứ như quy trình làm việc, lịch trình, người dùng, v.v.

Tôi sẽ thích di chuyển bán buôn. Có nội dung được quản lý bởi nhiều hơn một hệ thống là một vấn đề kỹ thuật lớn. Và tăng gấp đôi nỗ lực bảo trì của bạn.

Một điều tôi sẽ nói, đó là có thể đáng để thuê một người nào đó để làm điều đó. Đã có một số cuộc di cư Drupal rất thành công với bộ dữ liệu khổng lồ. Nhưng nếu bạn không có kinh nghiệm trong Drupal, bạn có thể thực hiện một số bước sai lầm và tốn nhiều thời gian. (Cá nhân tôi có thể giới thiệu cyrve , tôi không có liên kết hiện tại với họ)