현재 D8 상태에서 "노드"컨텐츠 엔티티의 컨텐츠 유형을 작성하는 것과 비교하여 새 컨텐츠 엔티티 유형을 작성하기위한 의사 결정 트리는 무엇입니까?

우리는 4 년 동안 Drupal 8의 첫 번째 릴리스는 " 엔터티를 만드는 것이 적절한가 ? 새로운 콘텐츠 유형을 추가하는 것이 적절한가 ?" 그리고 엔티티는 Drupal 7보다 Drupal 8의 중심에 있습니다 ( RefB , RefC , RefD )

이 새로운 Drupal 8 세계에서 "노드"유형의 컨텐츠 엔티티에 대한 새로운 컨텐츠 유형과 새로운 컨텐츠 엔티티 유형을 작성하기위한 의사 결정 트리는 무엇입니까?

응답을 고려할 때 다음을 고려하십시오.

• "노드"의 컨텐츠 엔티티 유형에 대한 새로운 컨텐츠 유형이 새로운 컨텐츠 엔티티 유형에 비해 99 % 상황에서 여전히 적절합니까?
• 의사 결정 트리에 "노드"컨텐츠 엔티티 유형을 사용하지 않고 새로운 컨텐츠 엔티티 유형을 작성해야하는 더 많거나, 더 나은 또는 더 명확한 이유가 포함됩니까? 그리고 그렇다면, 무엇입니까? 그들은 다음을 포함합니까?
  • 공연?
  • 보안 / 허가?
  • Node-entity-type Content-Type에서 작동하고 다른 Content 엔터티 유형과 작동하지 않는 모듈의 수는?
• 아마도-위에서 언급 한 이전에 허용 된 답변을 기반으로-사용자 정의 컨텐츠 엔터티 유형을 수행하는 유일한 일반적인 이유는 노드 데이터를 분류학 용어로 그룹화하거나 달리 주석으로 노드에 주석을 달고 싶기 때문입니까?

모듈 호환성은 의사 결정 트리에서 특히 흥미로운 고려 사항처럼 보입니다. 현재 가장 많이 설치된 모듈 중 일부는 알파, 베타 또는 rc (릴리스 후보)가 아닌 8.x 릴리즈가 있습니다. 그리고 새로운 사용자 지정 엔터티 유형과 새로운 노드 엔터티 콘텐츠 유형으로 기본적으로 얼마나 많은 기능을 사용할 수 있는지 파악하기가 어려워 보입니다. "엔티티 용으로 작성된"과 "노드 엔터티 컨텐트 유형용으로 작성된"속성을 구별하기위한 프로젝트 속성이없는 것 같습니다.

현재 모든 종류의 8.x 릴리즈가 설치된 모듈 중 네 번째로 설치된 모듈 인 pathauto를 살펴보십시오. 사람들은 일반적으로 노드 엔터티 유형의 컨텐트 유형뿐만 아니라 엔터티를 지원하는 8.x 버전 에서 열심히 노력 하고 있습니다. 그러나 다른 모든 모듈은 어떻습니까? 그리고 엔터티를 지원하는 모듈은 일반적으로 모듈과 함께 작동하기 전에 사용자 지정 컨텐트 엔터티 유형에 모듈 별 "후크"가 있어야합니까? (새로운 컨텐츠 유형을 사용하여 모듈을 바로 사용할 수있는 방법을 비교해보십시오.) 이는 경로 자동 팀이 해결해야하는 문제인 것처럼 보이며 아마도 사용자 정의 컨텐츠 엔티티 유형을 벗어나야하는 이유입니까?

Drupal 8 코어에는 "Node"유형의 콘텐츠 엔터티에 대한 새 콘텐츠 유형을 만들기위한 UI가 포함되어 있지만 현재 새 콘텐츠 엔터티 유형을 만들기위한 UI는 포함되어 있지 않습니다. ( RefX , RefY , RefZ )

새로운 노드 엔티티 유형 컨텐츠 유형과 새로운 컨텐츠 엔티티 유형 작성 사이에서 선택하기위한 의사 결정 트리 :

1. 프로그래머입니까, 아니면 프로그래머에게 쉽게 액세스 할 수 있습니까?
   • 그렇지 않다면 현재 새 노드 엔터티 콘텐츠 형식을 만드는 것으로 제한되어 있습니다. 새 컨텐츠 엔티티 유형을 작성하기위한 핵심 UI가 없으며 ECK (Entity Construction Kit) contrib 모듈에는 현재 알파 릴리스 만 있습니다.
   • 그렇다면 계속하십시오 ...
2. 데이터에 활용하려는 Contrib 모듈 을 정확히 알고 있습니까?
   • 그렇지 않다면, 아마도 안전한 방법은 노드 엔터티 콘텐츠 형식을 만드는 것입니다.
   • 그렇다면 해당 모듈이 이미 고려중인 사용자 지정 엔터티 유형을 지원합니까, 아니면 모듈에서 원하는 기능을 다시 만들거나 향상 시키도록 기꺼이 지원 하시겠습니까?
     • 그렇지 않은 경우 노드 엔터티 유형 콘텐츠 형식을 만드는 것이 가장 좋습니다.
     • 그렇다면 계속하십시오 ...
3. 모듈에서 활성화 한 실제 컨텐츠 데이터가 다른 컨텐츠 데이터를 그룹화하거나 주석을 달는 데 도움이됩니까? (그 자체로는 거의 볼 수 없습니다.)
   • 그렇다면, 모듈이 분류 용어 및 주석에 대한 기존 엔티티 유형과 같은지 고려하십시오. 그렇다면 새로운 엔터티 유형이 안전한 내기 일 수 있습니다.
   • 아니라면 계속하십시오 ...
4. 새로운 노드 엔티티 유형 컨텐츠 유형이 작동하지 않는 이유를 명확하게 설명 할 수 있습니까?
   • 그렇지 않다면 아마도 새로운 노드 엔터티 유형의 콘텐츠 유형을 만드는 것이 안전합니다.
   • 그렇다면 계속하십시오 ...
5. 마지막으로, 노드 엔터티 유형을 확장 할 수없고 CRUD 작업과 같은 유용한 기능을 모두 다시 작성 하시겠습니까?
   • 그렇다면 새 사용자 지정 엔터티 유형을 생성하십시오.
   • 그렇지 않은 경우 또는 확실하지 않은 경우 결정을 돕기 위해 일부 전문가를 참여시킬 수 있습니다.

노트:

1. 이 의사 결정 트리는 성능이나 보안을 고려하지 않습니다. 새 사용자 지정 콘텐츠 엔터티 유형이 노드 엔터티 유형보다 성능이 우수하고 보안 수준이 높거나 적은지 확실하지 않습니다.
2. 이 트리가 좋은 대답이더라도 Drupal 코어 및 contrib 모듈 릴리스의 업데이트로 인해 시간이 지남에 따라 하나도 유지되지 않을 것입니다. StackExchange는 오늘날 "최상의"답변이 내일 가장 적합한 답변이 아닌 방법을 수용하지 않는 것 같습니다.)

이 문제에 대한 간단한 접근 방식 은 프로젝트 목적, 규모 및 비즈니스 요구 사항을 고려하는 것입니다.

1. 어떻게 노드 개체의 콘텐츠 형식 가까이 아키텍처와 프로젝트 문서의 분석 사고에서 생산 데이터 흐름에 쉽게, 깔끔한 방법으로 프로젝트를 빌드 영향을 미치는 기본.

중요한 통지 여기에 새로운 개체 타입을 생성하는 결정은 일반적으로 개발자 나 기술 리드없는 사이트 빌더 또는 응용 프로그램을 관리하고 단지 사업에 초점을 프로젝트 소유자로했다.

2. Drupal 8 은 일부 symfony2 패키지에 의존하며 프레임 워크, 더 큰 아키텍처 변경으로 Drupal에 대해 이야기하는 전통적인 cms에 가깝습니다. 새로운 엔티티를 구축하는 것이 노드 엔터티 컨텐츠 유형에 대해 많은 사용자 정의 및 복잡한 구성을 순서대로 수행하는 것보다 낫습니다. 많은 사람들이 Drupal 구성 및 분산 설정 방식을 좋아하지 않기 때문에 Drupal을 다른 프레임 워크에서 활용하기 위해 WordPress에서 온 사람들이 Drupal 관리 대시 보드를 처리 할 때 짜증나는 한 가지 형식으로 모든 것을 구성하는 데 직면 할 수 있습니다.

3. Drupal 9 는 후크 시스템을 완전히 제거하고 이벤트 디스패처로 대체 할 계획이며 , 코드에서 기존 기능을 변경하는 것이 개발자가 아닌 사람들에게는 훨씬 어려울 수 있으므로 관리자 인터페이스가 새로운 엔티티를 작성해야 할 필요성이 커집니다. 해당 기능을 추가하십시오.

결국 , 프로젝트 요구에 맞게 조정 된 새로운 엔티티는 많은 필드를 가진 복잡한 컨텐츠 유형보다 더 나은 성능을 제공합니다. 이제 각 필드는 DB에 2 개의 테이블을 추가하고 각 요청에 대해 구성을로드해야합니다. 많은 비즈니스 로직이 필요합니다.

단순하고 단순함 : 모든 내용이 아닙니다. 컨텐츠 유형을 사용하는 경우 컨텐츠 목록이 상당히 길고 혼란 스러울 수 있습니다. ( ContentEntityBase 는 사용자 정의 엔티티 토글로도 구현 가능)

작성자와 게시 된 상태가있는 경우 컨텐츠 유형으로 이동해야합니다.

그렇지 않으면 (프로그래머를 가정 할 때) 사용자 지정 엔터티를 선호해야합니다. 모든 인터페이스 (수정 가능, 필드 가능, 액세스 제한 등)로 많은 것을 쉽게 구현할 수 있습니다.

내 생각에 이것은 더 명확하고 꼬리가 정렬 된 아키텍처 (및 성능이 뛰어남)입니다.

여러 프로젝트에서 재사용 가능성을 생각하면 사용자 지정 엔터티를 날려 버릴 수 있습니다. drupal-code-generator 와 같은 멋진 도우미도 있습니다 . 사용자 정의 코딩 (또는 복잡성)을 낮은 수준으로 유지하려면 원하는 경우 컨텐츠 유형 사용을 고려해야합니다.

• '엔티티'(적어도 D7)를 번역하려면 인터페이스도 있습니다.
• (제안을 위해여십시오) ..

솔직히 나는 당신이 전에 그것을 구현 한 후에 만 ​​이해된다고 생각하는 것은 어려운 질문입니다. 그러나 레미 metioned, 모든 것은 원시, 사용자가 콘텐츠에 직면하지 않습니다 .

Drupal 7에는 사용자 지정 엔터티를 만드는 기능이 있었지만 OOP로 인해 가장자리가 거칠면 어려운 작업이 될 수 있습니다. 그것은 절반의 구현 (또는 절반의 수행, 그러나 당신이 말하고 싶어)이었습니다. 이는 혼합 절차 및 혼합 OOP를 사용하여 접근법이 완전히 균일하고 합의되지 않은 엔티티를 만드는 방법으로 이어집니다.

Drupal 8에서는 아이디어가 훨씬 더 실현되었으며 사용자 지정 엔터티로 시작하고 실행하는 것이 훨씬 쉽습니다. 노드 자체는 블록, 사용자, 파일 및 분류와 같이 ContentEntityBase를 기반으로합니다.

노드는 특히 전형적으로 콘텐츠 역할 문서 콘텐츠 표시 (또는 승인) 데이터 (즉, 메뉴에서 또는 맵, 또는 XML 맵 또는 RSS 피드 등의). Drupal은 노드 조작 프로세스의 모든 단계에 연결하여 기여한 모듈이 잘못 혼합 된 경우 의도하지 않은 결과를 초래할 수있는 방식으로 설계되었습니다. 이것은 아마도 논쟁의 여지가있는 의견 일지 모르지만, Entity 개념을 더 포용하기 위해 "모든 것이 하나의 노드"라는 생각과 이혼하는 데 도움이됩니다.

훌륭한 컨텐츠 유형을 만드는 이상적인 컨텐츠 :

• 조
• 페이지
• 채용 공고
• 행사
• 방문 페이지
• 홈페이지

그들에게 공통적 인 스레드는 컨텐츠 유형의 개념을 공유한다는 것입니다. 일반적으로 사용자 지정 게시 옵션을 사용하는 경우 게시, 승격, 고정, 보관, 추천 등 다양한 워크 플로 상태에 있으며 많은 기여 모듈이 Pathauto와 같이 직접 상호 작용합니다.

그러나 내부, 개인, 다른 데이터를 구동하거나 허용하지 않는 한 범위를 벗어난 통합을 허용하지 않아야하는 데이터를 Drupal에 저장한다고 가정합니다. 어떤 종류의 데이터가 될 수 있습니까? 가능한 유형은 다음과 같습니다.

• 제품 (중앙 상거래)
• 광고 항목 (중복 상거래)
• 검색 서버 (ApacheSolr / SearchAPI)
• CRM 리드와 같은 연락처
• 티켓 (지원 티켓 등)

이것들이 왜 그렇게 다른가? 사용자 모델을 사용하는 대신 연락 할 엔티티를 원하는 이유는 무엇입니까? 거기에서 몇 가지 주장을 할 수는 있지만, 연락처 형식에서 전자 메일 주소와 이름 및 기타 메타 데이터를 수집하면 해당 데이터를 사용자 지정 엔터티로 저장하는 것이 좋습니다. 비 계정 항목으로 사용자 목록이 오염되는 것을 방지하고 잠재적 인 보안 문제를 줄입니다 (스크립트 나 누군가가 해당 계정을 실수로 관리자 나 대량 메일로 보낸 경우 어떻게됩니까?), 실제 사용자의 내부 오버 헤드 관리를 수행합니다. 계정을 쉽게 작성하고 캡처 한 내용을 특수한 데이터 비트로 분류합니다.

여기에서 Drupal / Node 시스템의보다 자동적 인 부분과 크게 다르며 작업과 경험을 조정할 수 있습니다. 경로, 액세스 및 CRUD 워크 플로우를 결정합니다.

그런 사고 방식에서 왜 그렇게 접근했는지를 쉽게 알 수 있습니다. 지원 티켓 예를 들어보십시오-들어오는 요청이지만 데이터가 게시되지 않았으며 준수하지 않으려는 노드 시스템의 일부와 이혼하는 것보다 쉽게 ​​설정할 수있는 매우 구체적인 워크 플로우가 있습니다. 에.

다른 예로는 가져온 외부 데이터가 있습니다. 대부분의 경우,이 데이터는 일반적으로 로컬 Drupal 데이터가 풍부하지 않습니다 (데이터가 존재하더라도 여전히 가능합니다). 무엇이든 될 수 있습니다. 아마도 청구서 일 수도 있고 책일 수도 있고 맥주 브랜드를 끌어들이는 것일 수도 있습니다.

이와 같은 데이터는 일반적으로 고유하며 노드가 의도 한 것 이상의 제어가 필요합니다. 즉, 노드의 참조 필드를 사용하여 사용자 지정 엔터티 (이는 Drupal Commerce가 특정 수준에서 작동 한 방식 임)를 가리 키도록하여 데이터를 보강함으로써 데이터를 보강 할 수는 없습니다. 동시에 잘못된 설계 코드에서 데이터와 UI를 설계하고 제어하는 ​​데 방해가되지 않고 데이터를 제어하고 제어합니다. 일부 후크가 남아 있지만 이것은 D8에서보다 D8에서 덜 문제가 될 수 있습니다.

적절한 아키텍처는 이제 분리를 장려하기 위해 존재합니다. 모든 것이 노드는 아닙니다.