핵심 Taxonomy 모듈 또는 Entity Reference 모듈 을 사용하기로 결정하는 방법이 궁금합니다 .

이전에 엔티티 참조 모듈을 사용하지 않았지만 10-15 웹 사이트에서 분류 모듈 (및 일부 관련 모듈)을 사용했습니다.

분류 모듈 대신 참조 기반 모듈을 사용할 때의 장단점은 무엇입니까?

최근에는 잡지 보관 웹 사이트를 구축하기 시작했습니다.

잡지가 많이 있습니다. 이 잡지에는 문제가 있습니다. 각 호에는 기사가 있습니다.

여기서 가장 작은 (그리고 가장 깊은) 부분은 기사 입니다.

조

• 페이지 번호 (범위) :
• 표제:
• 저자:
• 기사 유형 :
• 키워드 :
• 잡지:
• 발행물:

발행물

• 발급 번호 :
• 표지 이미지 :
• 날짜 (게시) :
• 잡지:

잡지

• 기술:
• 표지 이미지 :

이 웹 사이트를 구현하는 데는 적어도 2 가지 방법 이 있습니다.

1. 콘텐츠 유형이 있으며 article다른 모든 항목 (문제, 잡지, 저자)은 분류 용어 (계층 적)입니다. 이슈와 잡지 등의 계층 구조가 있습니다.

2. 기사, 이슈, 잡지, 저자 등 다양한 컨텐츠 유형이 있습니다. 기사를 작성하는 동안; 문제, 잡지 및 저자 등을 참조 할 수 있습니다.

이론적으로는 두 가지 방법이 매우 비슷해 보입니다.

비슷한 상황에 처한 사람이 있습니까? 왜 어떤 방법을 선호하는지 말할 수 있습니까?

문제에 대한 다른 해결책도 있습니다.

필드 콜렉션

당신이 사용할 수있는 필드 수집 및 필드 수집 뷰 저장소에 모듈과 내용을 구성 할 수 있습니다. 다음은이 방법을 사용 Issue하고 Magazine필드 컬렉션 타입이기 위하여려고하고, Issue의 필드 Article와 Magazine의 필드입니다 Issue. 그러한 구조를 구현 한 경험이 있습니다. 필자의 경우 요구 사항은 Library책 (제목, 출판사 및 ... 필드 포함)을 포함해야하며 모든 책에는 여러 권 (페이지 수, 번역기 등)이 포함되어 있으며 각 책에는 무제한의 다른 항목이 포함되어 있습니다 (도서에서 동일하지 않은 일부 페이지의 스캔과 같은).

Field Collection 접근법을 사용하여 이것을 구현했으며 매우 훌륭합니다. 모든 필드 컬렉션의 모든 개별 항목을 편집 할 수있는 링크를 쉽게 만들 수 있으며 필드 컬렉션의 항목별로 필터링 할 수도 있습니다. Field Collection Views로 작업하는 방법을 보여주는 Field Collection의 값을 기준으로 Views의 Group items에 대한 답변을 게시

엔터티 뷰 첨부

EVA 모듈 이라고도 합니다.

"Eva"는 "Entity Views Attachment"의 약자입니다. 그것은 Drupal 엔티티의 컨텐츠에 View의 출력을 첨부 할 수있는 Views 디스플레이 플러그인을 제공합니다. 노드 또는 주석의 본문, 사용자 계정의 프로필 또는 분류 용어의 목록 페이지는 모두 엔티티 컨텐츠의 예입니다.

EVA를 사용하여 특정 컨텐츠에 대한 필드 값만 표시 할 수 있으므로 필드의 표시 및 형식 유연성을 놀라 울 정도로 제어 할 수 있습니다. 예를 들어 두 가지 필드를 특별한 방식으로 연결하고자 할 수 있습니다. 필드를 EVA 디스플레이에 추가하고, 상황 별 필터를 NID로 설정하고, 전역 : 텍스트 필드를 추가하고, 토큰을 사용하여 HTML로 필드를 포맷 할 수 있습니다. 전역 : 텍스트 필드에서 필드를 함께 사용하려는 경우 필드를 표시에서 제외하는 것을 잊지 마십시오. 예 : 도시, 주 및 우편 번호 필드가있을 수 있습니다. 뷰의 전역 : 텍스트 필드에서 이들을 결합하여“도시, 주 ZIP”으로 표시 할 수 있습니다. 콘텐츠 유형의 디스플레이를 관리 할 때 방금 생성 한 EVA를 디스플레이에 추가하고 노드 유형이 표시 될 때마다 해당 유형을 EVA로 전달하고 EVA는 선택한 필드를 반환합니다. 당신이 원하는대로 형식. (출처 :EVA와 엔티티 참조 사용 사례 사용 방법 )

이 모듈은 완벽합니다. 컨텐츠 유형의 노드에보기를 필드로 연결합니다. 이 모듈을 사용하여을 만들었습니다 Album. 앨범에는 singer각각에 대한 정보 songs가 포함되어 있으며 파일, 제목, 요율 및 ...이 포함되어 있습니다. 그래서 EVA 유형의보기를 만들고 노드에 연결했습니다. 그래서 모든 가수의 노드 페이지에 노드에서 적절한 정보를 얻는이보기를 표시했습니다. 엔티티 참조 뷰는 이 모듈을 사용하는 방법에 대한 완벽한 튜토리얼입니다.

분류 용어 VS 엔티티 참조

난 당신이 읽을 것을 권장합니다 엔티티 참조 대 분류를 하고 기간 참조를 통해 엔티티 참조를 사용하여 어떤 혜택 /주의 사항이 있습니까? 분류 대로 유사한 항목을 구성 할 때 분류법을 사용하는 것이 가장 좋습니다. 태그처럼 .

분류 체계를 사용하면 새로운 태그를 즉석에서 생성 할 수있는 무료 태깅 ( 콘텐츠 분류법 모듈을 사용하여 비활성화 할 수 있음)을 사용할 수 있습니다 . 내용의 골격을 수정하는 것은 매우 쉽습니다. 이 방법을 사용하면 프로그래밍에 대한 지식이없는 일반 또는 인증 된 일부 사용자가이 스켈레톤을 변경할 수 있습니다. 계층 적 선택 모듈은 이러한 접근 방식의 완벽한 예입니다.

분류법은 사용하기 쉽지만 나 자신이 엔티티 참조를 선호하지만 많은 가능성과 확장 성을 열어 매우 복잡한 구조를 만들 수 있습니다. 이러한 맥락에서 실체의 개념은 내용에 국한되지 않는다. 댓글, 사용자, 분류 및 ...이 될 수 있습니다. 훨씬 확장 성이 뛰어나므로 콘텐츠 유형을 사용자 정의하거나 나중에 수정하는 것에 대해 걱정하지 않아도됩니다 ( Entity reference vs. taxonomy 에서 지적했듯이 ). Entity 접근 방식이 Taxonomy보다 강력하다고 생각합니다.

이러한 접근 방식을 언급 할 필요가없는 다른 조합도 있습니다.

어쨌든 엔티티 접근 방식과 관련 모듈을 완전히 이해하는 것이 좋습니다. 여러 프로젝트에서 사용하는 경우 복잡함에도 불구하고 사용하기가 매우 쉽습니다. 현재의 요구 사항뿐만 아니라 미래에도 매우 안정적인 도구가 될 것입니다.

기사와 이슈가 잡지가 분류 법인 노드와 같은 다른 조합을 가질 수도 있습니다.

이것에 대한 옳고 그른 대답은 실제로 개인 취향, 특정 프로젝트 요구 사항 등에 달려 있습니다.

콘텐츠에 대한 노드 및 분류법을 사용하여 해당 콘텐츠를 분류하는 것이 가장 좋지만, 때로는 콘텐츠가 분류인지 또는 자체 콘텐츠인지에 대해 약간 어둡게 보일 수 있습니다.

예를 들어 기사 유형 및 키워드 필드는 분류 체계 인 것처럼 보이지만 이슈와 잡지는 실제로 어느 쪽이든 갈 수 있습니다.

결정에 영향을 줄 수있는 한 가지는 바로 사용 가능한 기능입니다. 예를 들어, 분류 체계보다 노드에 대한 추가 기능 모듈이 훨씬 많지만 분류 체계의 경우 상자 목록 페이지 (원하는 경우)에서 벗어날 수 있습니다. 하나의 솔루션 또는 다른 솔루션으로 즉시 사용할 수있는 계층 구조 관련 기능이있을 수도 있습니다.

컨텐츠 유형 정의는 그림의 일부일뿐입니다. 콘텐츠를 사용자에게 제공하려는 방법, 사용자가 콘텐츠 계층 구조를 탐색하는 방법,이 콘텐츠가 사이트의 다른 콘텐츠와 어떤 관련이 있는지, 관리자가이를 관리하도록하려는 방법을 완전히 고려해야합니다. 예를 들어, 일종의 계층 적 메뉴 시스템을 원하거나 사람들이 잡지 나 발행 페이지로 이동하거나 기사 페이지에서만 볼 수있는 내용과 관련된 내용을 원하십니까? 3 가지 유형의 컨텐츠를 모두 나열하는 단일 검색을 원하십니까 (일부는 노드이고 분류는 용어 인 경우에는 사소하지 않을 수 있습니다).

모든 것을 계획 한 다음이를 달성하는 데 도움이되는 모듈을 확인하십시오. 원하는 것을 쉽게 달성 할 수있는 한 가지 방법을 찾을 수 있습니다. 그렇지 않다면 당신은 당신이 어떤 이유로 든 가장 좋다고 생각하는 것과 함께 가야합니다.

때때로 한 방향으로 가서 요구 사항을 달성하기 어려운 것을 찾을 수도 있습니다. 가능한 한 미리 계획하면 해당 위험이 줄어 듭니다.

"잡지"와 같은 분류법 용어를 사용할 때 고려해야 할 또 다른 사항은 해당 항목에 대한 수정 및 주석과 같은 기능을 잃게된다는 것입니다. 부여 된 개정판은 분류법 개정판 과 같은 모듈로 추가 할 수 있지만 설치 기반이 매우 낮은 모듈입니다. 개인적으로 나는 이것을 통해 노드의 개정 처리에 대한 핵심을 믿었습니다.

요구 사항의 변경으로 인해 프로젝트가 시작된 후 분류 용어에서 노드로 무언가를 변경해야 할 때가 적어도 하나 이상 있다고 생각할 수 있으며, 이는 약간의 구조 조정 및 마이그레이션과 관련이 있습니다.

entity_reference가있는 노드와 같은 다른 엔티티 유형을 사용하는 경우 모든 것이 거의 동일한 방식으로 작동하므로 변경하는 데 아무런 문제가 없지만 유연성이 향상됩니다.

나는 이것이 가장 정확한 대답이라고 말하지는 않지만 그것이 내가 생각하는 방식입니다. 몇 가지 예를 들어 설명하겠습니다.

나는 보통 분류법을 사용하여 추상화에 따라 노드를 분류합니다. 예를 들어, 뉴스는 스포츠, 정치 등으로 분류 될 수 있습니다.

그러나 잡지와 같은 참고 문헌을 원할 때 나는 미래에 대해 생각하고 있습니다. 사용자가 어떤 기사를 선택할지 결정하도록 도와 줄 때를 생각하십시오. 잡지 순위 (아마도 영향 요인)가 가능합니다. 아니면 그 잡지에 연락하고 싶을 수도 있습니다. 이 상황에서는 용어가 도움이되지 않습니다.

다른 한편으로 당신은 스스로 물건을해야합니다. 예를 들어 분류 용어를 클릭하면 해당 용어의 분류 된 노드로 채워진 페이지가 나타납니다. 이제 뷰와 컨텍스트 필터 등이 필요합니다.

누군가 내가 왜 필드 컬렉션에서 멀리 떨어져 있는지 물었을 것이라고 확신했지만 댓글은 삭제 된 것으로 보입니다. 어느 쪽이든 내 2 센트 :

분류법은 분류 및 분류에 사용되어야합니다. 콘텐츠 관계에 적합하지 않습니다. 분류 용어를 통해 2 개의 컨텐츠를 연결하면 2 개만 필요한 3 개의 엔티티를 사용하게됩니다.

내 경험상, 분류 체계는 이제 현장 화가 가능하지만 본격적인 실체는 아니므로 "콘텐츠"로 사용해서는 안된다.

이 특별한 경우, 매거진에 컨텐츠 (내용에 대한 설명, 주문에 대한 세부 사항 등) 또는 "페이지"가있는 경우 컨텐츠이기 때문에 컨텐츠 유형이어야합니다.

문제는 약간 모호하지만 개요 등이 있으므로 페이지가 있거나 내용이있을 가능성이 높습니다. 다른 컨텐츠 유형입니다.

기사는 분명히 내용 유형입니다.

이를 위해 관리자를 빌드 할 때 엔티티 참조를 사용하여 이러한 컨텐츠를 링크 할 수 있지만 한 단계 더 나아갈 수 있습니다.

@Drupalist가 Field Collections 사용을 제안한 것과 같은 방식으로 인라인 엔티티 양식을 사용할 수 있습니다 (Entity Reference의 일부라고 생각합니다). 필드 컬렉션은 이러한 오래된 모듈 중 하나이며, 잘 구현되지 않았으며 다른 모듈과 충돌이 많은 훌륭한 아이디어입니다. 그들은 이제 엔티티이지만 여전히 문제가 있으며, 저자와 같은 것들에 대해 본격적인 엔티티 (콘텐츠 유형 포함)를 사용하는 것이 좋습니다.

인라인 엔터티 양식을 사용하면 참조하려는 엔터티 내부에서 참조 된 엔터티를 생성 및 편집 할 수 있습니다. 따라서 기사 내부에서 작성자를 생성 / 편집하거나 이미 만들어진 엔터티를 참조 할 수 있습니다.

CER에 추가하면 작성자에서 기사로, 기사에서 이슈로, 이슈를 다시 잡지로, 또는 어떤 방향 으로든 참조가 자동으로 제공됩니다. 이는보기의 성능에 이점이 있지만,보기없이 기사 페이지에 기사 목록을 표시하고 기사 페이지에 저자 정보를 표시 할 수도 있습니다.

분류법으로 다시 돌아 가면, "낚시", "자동차", "컴퓨터"등 / 물건 등을 사용하여 기사 등에 "태그"를 붙이기 위해 모든 문제, 잡지, 기사를 찾을 수 있습니다. 또는 해당 태그에 대한 내용이 있거나 작성된 저자.

간단히 설명하려고 노력 했으므로 도움이되고 말이됩니다. 수십 개의 사이트에서이 작업을 수행했습니다. 글로벌 스포츠 행사, 여행 / 휴일 예약 사이트, 국제 방송사, 음료, 자선 단체 등 강력하고 강력하며 예상치 못한 요구 사항을 충족시켜줍니다.