많은 사용자 정의 필드가있는 연락처 및 약속 목록을 포함하는 양식을 사용자가 컴파일 할 수있는 Drupal 사이트를 개발해야합니다. 내가 더 나은 Drupal : 사용자 정의 테이블 또는 CCK?
; 및
내가 CCK 나를 위해 작업의 일부를 만드는 것을 알고 있지만 나는 그것을 만들고 필드를 취급 조금 무거운를 찾을 수를 사용하여 CCK 테이블을 가지고.
귀하의 의견은 무엇입니까?
Drupal 커뮤니티는 MPD의 답변과 함께 주로 CCK와 Views를 사용합니다.
개인적으로, 나는 거의 그 좋은 해결책을 찾지 못했습니다. IMO Views와 CCK가 시간과 노력에 실질적인 이점을 제공하는 유일한 곳은 최종 결과가 잘못되었거나 느슨하게 정의 된 경우입니다. 그러나 와이어 프레임, 목업 또는 디자인을 사용하려면 views + cck에 lot of undoing이 필요합니다.
또 다른 중요한 고려 사항은 배포가 부족한 Drupals입니다. 너무 자주 CCK +보기를 만들고 테마 소스와 사용자 정의 (양식 변경) 코드를 던집니다. 그런 다음 기회가 잘못되었습니다. 새 구성 (예 : 사용자가 정의한 새 CCK 필드)없이 테마가 손상됩니다. 그러나 새로운 테마가 없으면 새로운 CCK 필드가 끊어집니다. 일부 다운 타임으로 "해결"되는 드루팔 (Drupal)에서는 새로운 코드가 롤아웃되고 곧이어이 필드를 수동으로 재구성합니다. 강건 함이나 기능의 형태로 이에 대한 몇 가지 복잡한 "해결책"이 있지만.
결국 CCK, Views, bucketload of CCK fields-modules, VIEW addons 및 많은 gluecode로 끝날 것입니다. 테마 측면에서 보면 Div에 감염된 큰 오버라이드로 끝납니다.
이 모든 작업은 단일 최적화되고 깨끗한 모듈로 간단하고 유지 보수가 잘되며 최적화 된 맞춤 모듈에서 가능합니다.
모든 것이 집에서 코드로 어떻게 느껴지는가? 필자는 개인적으로 (깨끗하고 잘 구조화 된) PHP 몇 줄을 시작하는 것에 신경 쓰지 않는다. 다른 사람들은 코딩을 선호하고 주위를 클릭하는 것을 선호합니다. (제 경험으로 말하면 결국 더 복잡한 인터페이스에 대한 코딩이 끝납니다)
나는이 사실에 동의하지 않겠지 만 모든 경우에 "크고 div로 감염된"무시가 사실이라고 말하지는 않습니다. 뷰 UI가 아닌 필드를 포맷하고 좋은 뷰 템플릿을 사용하여 깨끗한 HTML을 얻을 수 있습니다. 나는 또한 비 코드 측면이 좋은 것이라고 주장 할 것이다. 기술 분야가 아닌 사람들에게 기본적인 콘텐츠 유형 및보기를 작성한 다음 멋진 콘텐츠를 얻기 위해 나에게 제공 할 수 있습니다. 그렇지 않은 경우 CCK가 아닌 옵션을 상당히 잘 요약했기 때문에이 표를 사용했습니다. – mpdonadio
좋은 뷰 템플릿을 사용하면 뷰의 큰 목적을 벗어납니다. 웹 인터페이스를 변경하려면 * 템플릿의 변경이 필요합니다. 당신은 빡빡한 방법으로 설정에 코드를 연결합니다. – berkes
CCK가 다른 Drupal 모듈 (특히 Views)과 긴밀하게 통합되어 있기 때문에 개인적으로 CCK 필드가있는 사용자 정의 컨텐츠 유형을 사용하는 것이 거의 언제나 최선의 선택이라고 생각합니다.
Drupal의 버전을 지정해야합니다. CCK는 7에서 핵심으로 이동했고 API를 가지고있다. :) – Rimian
7에 대한 의견이 준비되지 않았기 때문에 대부분 6 일 것입니다. – berkes
예, 드루팔 (Drupal)입니다. 6 – Cris