19 марта 2009 в 18:21
Вот в принципе сабж. Читал много похожего но конкретного ничего нет. Написать модуль, для меня, в принципе не проблема но стоит ли оно того? Допустим планируется грандиозная форма для определенного типа документа ~50-60 полей... как это скажется на работе CCK? и ещё одно, не нашёл я что то в Views доступа к полям созданным в CCK, где их искать?
И вообще был бы примного благодарен если бы кто нибудь смог объяснить в каких случаях стоит писать свой модуль.
ну и ещё вопрос) Как убрать все ненужные филдсеты("Установки комментариев", "Информация об авторе" и т.д.) из стандартной формы?
Комментарии
при 50 - 60 полей конечно только собственный модуль, после 10 полей уже стоит начинать
зайти не под админом!
Как бы в семерке cck включен в ядро и это о чем-то говорит, для него море готовых типов полей и это подкупает, не нужно делать свои велосипеды. Хотя тоже вполне могу написать свой модуль - в этом большой плюс (помимо видимо скорости) что ясно представляешь себе весь процесс и структуру хранения и можно быть уверенным что ее никто не поменяет кроме тебя
В принципе можно свой и потом его интегрировать с views (он только показывает так что ничего особо страшного, если что можно выключить и сделать свою выборку). Еще стоит учитывать цель сайта, если для себя с цель его развивать и в техническом плане, то можно свой модуль, если кому-то другому, то возможно лучше cck.
50 полей -- это однозначно самописный модуль, предоставляющий свой тип материала, так как CCK будет сильно тормозить. Возможностей таксономии и шаблонизации точно не хватит? Ведь значения терминов можно выводить как поля CCK с помощью шаблонов.
Не вижу разницы между 3 полями и 50-ю. Покажите.
arlamar, если вы не знаете что лучше, используйте CCK.
Честно говоря иногда мне проще написать своё чем разобраться в существующем... Вроде ничё не мешает создать 50 полей, НО как подумаешь сколько CCK должен проделать для хранения самих полей и их содержимого. из этих 50 полей половина селекты значит ещё ему надо хранить кучу значений... ну может конечно всё не так страшно как я себе представил)
а одно мне вапще покоя не даёт как достать значение селектов CCK полей? допустим мне надо аяксом грузить половину этих селектов. так тут ещё придётся при создании полей продумывать будущие связи...
Описания полей хранятся в content_node_field и content_node_field_instance - эти значения читаются при построении формы, далее форма кэшируется.
Когда вы создаёте хотябы одно поле CCK, создаётся таблица content_type_ВАШ-ТИП-МАТЕРИАЛА содержащая столбцы-поля. Вы конечно обойдётесь без content_node_field_instance и content_node_field, но это, в принципе, и вся экономия.
А аяксом грузить можно пользуясь АПИ или читая напрямую из таблицы (одной).