Với trạng thái D8 hiện tại, cây quyết định nào để tạo loại thực thể nội dung mới so với việc tạo Loại nội dung cho thực thể nội dung Node mật?

Chúng tôi đã thấy bốn năm và bản phát hành đầu tiên của Drupal 8 kể từ khi câu trả lời được chấp nhận được viết cho câu hỏi " Khi nào thì thích hợp để tạo một Thực thể thay vì chỉ thêm một loại nội dung mới ?" Và, các thực thể tập trung vào Drupal 8 hơn so với Drupal 7. ( RefB , RefC , RefD )

Trong thế giới Drupal 8 mới này, cây quyết định tạo loại thực thể nội dung mới so với Loại nội dung mới cho thực thể nội dung của loại "Nút" là gì?

Khi bạn xem xét một phản hồi, xin vui lòng xem xét những điều sau đây:

• Loại Nội dung mới cho loại thực thể nội dung của "Nút" vẫn phù hợp trong 99% tình huống so với loại thực thể nội dung mới?
• Bây giờ cây quyết định bao gồm nhiều lý do hơn, tốt hơn hoặc rõ ràng hơn để tránh sử dụng loại thực thể nội dung "Nút" và thay vào đó tạo ra một loại thực thể nội dung mới? Và nếu có, họ là gì? Họ có bao gồm:
  • Hiệu suất?
  • Bảo mật / quyền?
  • Số lượng mô-đun hoạt động với Kiểu nội dung kiểu Node và không hoạt động với các loại thực thể nội dung khác?
• Có lẽ - dựa trên câu trả lời được chấp nhận trước đó được tham chiếu ở trên - lý do chung duy nhất để thực hiện loại thực thể nội dung tùy chỉnh là nếu bạn muốn nhóm dữ liệu Node, ví dụ như với các thuật ngữ phân loại hoặc chú thích Node, ví dụ như với các bình luận?

Khả năng tương thích mô-đun có vẻ như là một xem xét đặc biệt thú vị cho một cây quyết định. Hiện tại, một vài trong số các mô-đun được cài đặt nhiều nhất có bản phát hành cho 8.x không chỉ đơn thuần là alpha, beta hoặc RC (một ứng cử viên phát hành). Và có vẻ khó xác định có bao nhiêu trong số chúng sẽ hoạt động ngoài luồng với loại thực thể tùy chỉnh mới so với loại nội dung Node-thực thể mới. Dường như không có một thuộc tính dự án nào để phân biệt giữa các thuộc tính "được viết cho các thực thể" so với "được viết cho các loại nội dung thực thể nút".

Hãy xem pathauto, hiện là mô-đun được cài đặt nhiều thứ tư trong số những mô-đun có bất kỳ loại phát hành 8.x nào. Mọi người đang làm việc chăm chỉ trên phiên bản 8.x thường hỗ trợ các thực thể và không chỉ các loại Nội dung kiểu Node. Nhưng những gì về tất cả các mô-đun khác? Và các mô-đun hỗ trợ các thực thể sẽ thường yêu cầu các loại thực thể nội dung tùy chỉnh phải có các "móc" dành riêng cho mô-đun trước khi mô-đun hoạt động với chúng? (So ​​với cách các mô-đun có thể hoạt động ngay lập tức với các loại Nội dung mới?) Đó có vẻ là loại thách thức mà nhóm pathauto đang làm việc và có lẽ đó là lý do để xoay chuyển khỏi loại thực thể nội dung tùy chỉnh?

Cũng có thể đáng nói rằng lõi Drupal 8 chứa UI để tạo Loại nội dung mới cho thực thể nội dung loại "Nút", nhưng hiện tại nó không chứa UI để tạo loại thực thể nội dung mới. ( RefX , RefY , RefZ )

Cây quyết định để chọn giữa việc tạo Loại nội dung kiểu thực thể nút mới so với loại thực thể nội dung mới:

1. Bạn có phải là một lập trình viên, hoặc bạn có dễ dàng truy cập vào một lập trình viên?
   • Nếu không, thì hiện tại bạn bị giới hạn khá nhiều trong việc tạo các kiểu nội dung Node-thực thể mới. (Không có UI trong lõi để tạo các loại thực thể nội dung mới và mô-đun đóng góp Entity Construction Kit (ECK) hiện chỉ có bản phát hành alpha.)
   • Nếu có, thì tiếp tục ...
2. Bạn có biết chính xác mô-đun đóng góp nào bạn muốn tận dụng cho dữ liệu của mình không?
   • Nếu không, thì đặt cược an toàn có lẽ chỉ là tạo Kiểu Nội dung Node.
   • Nếu có, các mô-đun đó đã hỗ trợ (các) loại thực thể tùy chỉnh mà bạn đang xem xét chưa, hoặc bạn có sẵn sàng giúp nâng cao chúng để chúng sẽ hoặc tạo lại chức năng mong muốn trong mô-đun của bạn không?
     • Nếu không, thì chỉ cần tạo Kiểu Nội dung kiểu Node có thể là tốt nhất cho bạn.
     • Nếu có, thì tiếp tục ...
3. Dữ liệu nội dung thực tế được kích hoạt bởi mô-đun của bạn chỉ giúp nhóm hoặc chú thích dữ liệu nội dung khác? (Vì vậy, nó sẽ hiếm khi được xem trên chính nó.)
   • Nếu có, sau đó xem xét liệu mô-đun của bạn có giống như các loại thực thể hiện tại cho các điều khoản và nhận xét phân loại hay không. Nếu đúng như vậy, thì một loại thực thể mới có thể là cược an toàn.
   • Nếu không, thì tiếp tục ...
4. Bạn có thể nói rõ tại sao Loại Nội dung kiểu Node mới sẽ không hoạt động cho bạn không?
   • Nếu không, thì đặt cược an toàn của bạn có lẽ chỉ là tạo Loại Nội dung kiểu Node mới.
   • Nếu có, thì tiếp tục ...
5. Cuối cùng, bạn có chắc chắn rằng bạn không thể mở rộng loại Node-thực thể và bạn muốn tạo lại tất cả các chức năng hữu ích của nó như các hoạt động CRUD?
   • Nếu có, sau đó tiếp tục và tạo một loại thực thể tùy chỉnh mới.
   • Nếu không, hoặc nếu bạn không chắc chắn, thì có lẽ bạn muốn thu hút một số chuyên gia để giúp bạn quyết định.

Ghi chú:

1. Cây quyết định này không xem xét hiệu suất hoặc bảo mật. Tôi không chắc chắn nếu hoặc khi một loại thực thể nội dung tùy chỉnh mới sẽ hoạt động tốt hơn và an toàn hơn hoặc ít hơn loại thực thể Node.
2. Ngay cả khi cây này là một câu trả lời tốt, nó có thể sẽ không còn tồn tại theo thời gian do các bản cập nhật trong các bản phát hành mô-đun lõi và đóng góp của Drupal. StackExchange dường như không phù hợp với cách câu trả lời "tốt nhất" hôm nay có thể không phải là câu trả lời hay nhất vào ngày mai.)

Một cách tiếp cận đơn giản về vấn đề đó là xem xét mục đích, quy mô và yêu cầu kinh doanh của dự án.

1. Làm thế nào loại nội dung nút thực thể mặc định ảnh hưởng đến việc xây dựng dự án một cách dễ dàng, gọn gàng gần hơn với kiến ​​trúc và luồng dữ liệu được tạo ra từ suy nghĩ phân tích của tài liệu dự án.

Một thông báo quan trọng ở đây là quyết định tạo loại thực thể mới thường được đưa ra bởi các nhà phát triển hoặc lãnh đạo kỹ thuật chứ không phải người xây dựng trang web hoặc chủ dự án quản lý ứng dụng và chỉ tập trung vào kinh doanh.

2. Drupal 8 phụ thuộc vào một số gói symfony2 và gần với khung hơn, sự phát triển mà các cm truyền thống nói về Drupal với những thay đổi kiến ​​trúc lớn đó, tôi hình dung việc xây dựng một thực thể mới tốt hơn là thực hiện nhiều cấu hình tùy biến và phức tạp trên các loại nội dung thực thể nút theo thứ tự để thúc đẩy Drupal trong số các khung công tác khác vì nhiều người không thích cách cấu hình và cài đặt phân tán của Drupal, Bạn có thể phải đối mặt với một số người đến từ WordPress và sử dụng để định cấu hình mọi thứ từ một hình thức khiến họ khó chịu khi giao dịch với bảng điều khiển quản trị viên Drupal.

3. Drupal 9 có kế hoạch loại bỏ hoàn toàn hệ thống hook và thay thế bằng bộ điều phối sự kiện dẫn đến nhu cầu lớn về giao diện quản trị để tạo một thực thể mới vì việc thay đổi chức năng hiện có từ mã sẽ khó hơn nhiều đối với những người không phải là nhà phát triển và sẽ rất cần thiết thêm tính năng đó

Cuối cùng , tôi thấy các thực thể mới phù hợp với nhu cầu của dự án mang lại hiệu năng cao tốt hơn các loại nội dung phức tạp với số lượng trường lớn vì hiện tại mỗi trường thêm 2 bảng vào DB và cần tải cấu hình của nó theo từng yêu cầu, đặc biệt là với logic kinh doanh nặng cần thiết.

Đơn giản và đơn giản: Đó không phải là tất cả nội dung. Danh sách nội dung có thể khá dài và khó hiểu nếu bạn chỉ sử dụng các loại nội dung. ( ContentEntityBase cũng có thể được triển khai bởi một thực thể tùy chỉnh thoe)

Nếu bạn có một tác giả và nhà nước xuất bản, bạn nên chọn loại nội dung.

Mặt khác (giả sử một lập trình viên của bạn) các thực thể tùy chỉnh nên được ưu tiên. Rất nhiều có thể được thực hiện dễ dàng với tất cả các giao diện (như có thể sửa đổi, có thể có trường, hạn chế truy cập, v.v.)

Theo quan điểm của tôi, đây chỉ là kiến trúc rõ ràng hơn và được sắp xếp theo thứ tự (và cũng có hiệu suất cao hơn).

Suy nghĩ về khả năng sử dụng lại trong một số dự án, nỗ lực làm cho các thực thể tùy chỉnh nổ tung .. cũng có những người trợ giúp tiện lợi như drupal-code-tạo . Để giữ mã hóa tùy chỉnh (hoặc độ phức tạp) ở mức thấp, bạn nên xem xét sử dụng các loại nội dung nếu bạn muốn:

• Để dịch 'thực thể' (ít nhất là trong D7), cũng sẽ có một giao diện.
• (mở để góp ý) ..

Đó là một câu hỏi khó mà thật lòng tôi nghĩ chỉ được hiểu một khi bạn đã thực hiện nó trước đó. Nhưng như remyed, không phải tất cả mọi thứ là thô, nội dung người dùng phải đối mặt .

Trong Drupal 7, khả năng tạo các thực thể tùy chỉnh đã tồn tại, nhưng có thể là một nhiệm vụ khó khăn nếu bạn thô ráp xung quanh các cạnh với OOP. Đó là loại được thực hiện một nửa (hoặc thực hiện một nửa, tuy nhiên bạn muốn nói), điều này dẫn đến các cách tạo ra các thực thể không hoàn toàn thống nhất và theo các cách tiếp cận, với OOP theo thủ tục và hỗn hợp.

Trong Drupal 8, ý tưởng được hiện thực hóa nhiều hơn và việc lên và chạy với một thực thể tùy chỉnh sẽ dễ dàng hơn rất nhiều. Bản thân nút được dựa trên ContentEntityBase, cũng như Khối, Người dùng, Tệp và Phân loại.

Các nút dành riêng cho dữ liệu nội dung được công bố, hiển thị (hoặc được ủy quyền) thường hoạt động như nội dung (nghĩa là trong menu hoặc trong sơ đồ trang web, hoặc sơ đồ trang web xml hoặc nguồn cấp dữ liệu RSS, v.v.). Drupal được thiết kế theo cách mà bạn có thể nối vào bất kỳ bước nào của quy trình vận hành nút và thay đổi nó có thể gây ra hậu quả ngoài ý muốn nếu bạn kết hợp sai các mô-đun đóng góp. Đây có lẽ là một ý kiến ​​gây tranh cãi, nhưng nó giúp bạn tự ly dị với ý tưởng "mọi thứ là một nút" để nắm lấy khái niệm Thực thể nhiều hơn.

Nội dung lý tưởng tạo ra các loại nội dung tuyệt vời:

• Bài báo
• Trang
• Đăng việc
• Biến cố
• Trang đích
• Trang chủ

Chủ đề chung cho họ là họ chia sẻ một khái niệm về một loại nội dung. Nó thường ở bất kỳ trạng thái dòng công việc nào (được xuất bản, được quảng bá, dính, lưu trữ, đặc trưng, ​​v.v. - nếu bạn sử dụng tùy chọn xuất bản tùy chỉnh) và một số lượng lớn các mô-đun đóng góp tương tác trực tiếp với nó, như Pathauto.

Nhưng giả sử bạn muốn lưu trữ dữ liệu trong Drupal là nội bộ, riêng tư, điều khiển dữ liệu khác hoặc dữ liệu không cho phép tích hợp ngoài phạm vi của nó trừ khi bạn cho phép. Loại dữ liệu này có thể là gì? Dưới đây là một số loại có thể:

• Sản phẩm (Thương mại Drupal)
• Mục hàng (Thương mại Drupal)
• Máy chủ tìm kiếm (ApacheSolr / SearchAPI)
• Liên hệ (như lãnh đạo CRM)
• Vé (như vé hỗ trợ)

Điều gì làm cho những điều này rất khác nhau? Tại sao bạn muốn có một thực thể để liên lạc, thay vì sử dụng mô hình Người dùng? Bạn có thể đưa ra một vài đối số ở đó, nhưng ví dụ của tôi sẽ là nếu bạn nói, thu thập địa chỉ email và tên và một số dữ liệu meta khác từ biểu mẫu liên hệ, lưu trữ dữ liệu đó dưới dạng thực thể tùy chỉnh. Bạn ngăn danh sách người dùng bị ô nhiễm với các mục không phải tài khoản, bạn giảm các vấn đề bảo mật tiềm ẩn (nếu tập lệnh hoặc ai đó vô tình cập nhật các tài khoản đó thành quản trị viên hoặc gửi thư hàng loạt?), Bạn có thể quản lý chi phí nội bộ của người dùng thực tế tài khoản dễ dàng hơn và bạn phân đoạn những gì bạn đang nắm bắt được nó là gì, một chút dữ liệu chuyên biệt.

Từ đây, phần lớn đã ly dị với các bộ phận tự động hơn của hệ thống Drupal / Node và bạn có thể điều chỉnh các hành động và trải nghiệm. Bạn xác định các tuyến đường, truy cập và luồng công việc CRUD.

Trong suy nghĩ đó, nó giúp dễ dàng hơn để xem tại sao cách tiếp cận đó sẽ được thực hiện theo cách đó. Lấy ví dụ về vé hỗ trợ - đó là các yêu cầu đến, nhưng không được công bố dữ liệu và có khả năng có một quy trình công việc rất cụ thể, dễ dàng thiết lập theo cách của bạn hơn là tách nó khỏi các phần của hệ thống nút mà bạn không muốn nó tuân thủ đến.

Một ví dụ khác là dữ liệu bên ngoài, nhập khẩu. Trong hầu hết các trường hợp, dữ liệu này thường không được làm giàu với dữ liệu Drupal cục bộ (ngay cả khi nó là một thực thể, bạn vẫn có thể làm điều đó). Nó có thể là bất cứ điều gì. Có thể đó là hóa đơn, có thể chúng là sách, có thể nó đang kéo các nhãn hiệu bia.

Dữ liệu như thế này thường cụ thể và yêu cầu kiểm soát ngoài ý nghĩa của nút. Điều đó không có nghĩa là bạn không thể gia tăng nó bằng cách sử dụng trường tham chiếu trên một nút để trỏ đến thực thể tùy chỉnh của bạn (đây là cách mà Drupal Commerce hoạt động, ở một mức độ nào đó) để làm phong phú dữ liệu. Đồng thời, bạn đang cách ly và đảm bảo quyền kiểm soát dữ liệu và giao diện người dùng của bạn khỏi mã đóng góp sai lầm vượt ra ngoài thiết kế và can thiệp vào mô hình của bạn. Đây có thể là một vấn đề ít hơn ở D8 so với D7, mặc dù vẫn còn một số móc.

Các kiến ​​trúc thích hợp hiện tồn tại để khuyến khích sự tách biệt. Không phải tất cả mọi thứ là một nút.