26 января 2010 в 12:21
Коллеги, хотелось бы узнать как вы решаете проблему создания единичных статичных страниц (к примеру "О компании"), если кроме стандартного заголовка и текста (тип контента Page), требуется добавить к форме редактирования страницы дополнительные поля.
Поясню свой вопрос:
Создать тип контента с произвольным набором полей легко - CCK или же hook_node_info + hook_form + ...
Но определение нового типа контента подразумевает в дальнейшем создание множества страниц этого типа. Однако, что делать, если нам нужна только одна страница с определенным набором полей?
Подозреваю, что для решения такой насущной задачи существуют стандартные методы, возможно, какие-то модули, но пока ничего не нашел.
Комментарии
Статичная страница не приходит одна
я обычно делаю тип материала, куда пихаю все ССК поля которые могут быть по ТЗ для статических страниц, а дальше на шаблоне или на hook_nodeapi вывожу только те значения которые заполнены для той или иной ноды. Может и кривое решение, но другое пока в голову не приходило.
Подобные извращения и я проделывал. Хотелось бы услышать о каких-то более изящных способах
Подпишусь на темку.
Как облить грязью очередной гавнасайт, желающих хоть отбавляй, а как пораскинуть мозгами на интересную темы — ни души )
Своя форма.
Какие ещё варианты, если Вы не хотите создавать новый тип материала? Хотя криминала в создании типа материала не вижу, даже если статей там будут единицы - главное чтобы клиенту было понятно.
Вы, возможно, не совсем поняли вопрос.
Концепция «тип контента» заключается в том, что на основе типа контента можно создавать множество страниц данного типа. Это как тип данных в программировании: переменных определенного типа может быть куча.
Создавать новый тип контента для одной страницы - это концептуально неверно, поскольку это позволит создавать неограниченное количество страниц данного типа, а нам нужно ограничить пользователя возможностью создать только одну страницу а в дальнешйем только редактировать ее.
Я вижу это следующим образом:
Наравне с Типами контента есть некие Страницы. Мы можем создать новую страницу (скажем, «О компании»), определить по аналогии с созданием нового типа контента набор полей для этой страницы и определить URL адрес этой страницы.
Далее, скажем по адресу admin/content/page мы видим список всех страниц и ссылки на редактирование (наполнение контентом) страниц.
чем неустраивает стандартный тип page + html код в теле ? какой смысл в cck ?
Тем что мои клиенты, к сожалению, никак не хотят осваивать HTML.
Да и, кроме того, одним HTML-ем не всегда можно обойтись.
Представьте, что на странице нужно вывести текст, большую фотографию сверху слева, и карусель с произвольным числом картинок под контентом.
Подпишусь. Очень актуально.
Модуль upload и html ручками. А то что клиент html не знает - не проблема, будет заказывать редактирование у Вас.
Вообще-то Вы используете друпал не по назначению. Подобная проблема может возникнуть на сайтах визитках, у которых всего 10 страниц и каждая - с уникальным дизайном. На средних и крупных сайтах такого удовольствия не будет.
А Вам, кстати, вполне может подойти webform.
А если и это не подходит, то, опять же, - своя форма и свой вывод.
Ограничить пользователя созданием одной страницы того или иного типа вообще не проблема, кода на три - 4 строчки максимум, хоть роли, хоть вообще по всем пользователям включая суперадмина запрет можно наложить. т.е. проверять условие если нода такого типа есть, то гаплык больше не создавать а лучше вообще закрыть доступ к странице создания ноды этого типа, только культурно это обозвать а не access denied.
hook_menu_alter - этот пункт меню вообще изчезнет из системы.
Да способов немеряно. В любом случае даже если необходим сайт визитка на 10 различных страниц, так создайте 10 типов материалов. и ограничьте юзера в дальнейшем расплодении нод.
Да, меня тоже поразила такая схема работы после перехода с TYPO3, в TYPO3 есть типы контента (текст, картинка, текст с картинкой и т.д., расширяемо за счёт доп. модулей) и пользователь может накидывать нужные типы, к которым он имеет доступ на страницу (аналог ноды, но сразу с привязкой к меню) и заполнять их. Соответственно, можно эти куски перемещать в нужном порядке, скрывать, удалять. Ну и редактируется в одном месте.
А в друпале, как я понимаю, такую схему можно реализовать через views, но очень неудобно, т.к. нужно насоздавать нод в одном месте, в каждой аккуратно прописать путь, чтобы вью заработала, а потом уже на самой странице, где эти ноды появятся, входить в каждую и выставлять вес, чтобы в правильном порядке они отображались.
Так что да, проще всё в виде HTML делать, хоть кусок этого HTML не скроешь, а только удалишь, если нужно пользователю.