Тип контента Drupal (ресторан) дизайн

Тип содержимого РЕСТОРАН. Поля для названия компании, служебного адреса, телефона, факса, веб-сайта, электронной почты, IM, Twitter, владельца бизнеса, делового контакта (например, менеджера), описания ресторана, логотипа и ссылки на местоположение на карте Google (или реализации модулей местоположения и gmap) и т. Д. Может быть, использовать пятизвездочный модуль, чтобы пользователи могли оценивать рестораны.

Единая иерархическая таксономия (для этого нужен модуль). Категории продуктов питания - это напитки (алкогольные, безалкогольные и т. Д.), Супы, салаты, завтраки, обеды, ужины, десерты, первые блюда, бутерброды, морепродукты и т. Д.

Тип содержания FOOD. Поля для поля ссылки узла на название РЕСТОРАНА, чтобы их меню было построено и организовано правильно, выбор иерархической таксономии FOOD, название еды (McRib, Whopper, Bloomin Onion и т. Д.), Цена, варианты приготовления (средний, хорошо прожаренный и т. Д.) ), изображения продуктов питания и дополнения, которые могут быть объединены с этим блюдом, должны быть либо вариантами списка выбора, либо ссылками на другие типы содержимого продуктов питания (пюре или печеный картофель с этим?)

Что касается изображений, используйте кэш изображений для создания несколько разных полезных размеров всех фото, так что вы можете делать крошечные эскизы, изображения среднего размера и полноразмерные великолепные фото блюд.

Отображение в CSS, напоминающее меню. Посмотрите на сайты национальных ресторанов, такие как Chilis.com, чтобы узнать, как они это делают. Предоставьте ссылки на меню терминов таксономии продуктов питания для каждого ресторана, и вид ресторанов с открытыми фильтрами, чтобы пользователи могли легко находить рестораны по типу, местоположению, звездной оценке и т. д.

Звучит как забавный проект. Когда вы закончите, я хотел бы, чтобы опубликовали тематическое исследование.

Я бы сделал это, вероятно, следующим образом:
Обратите внимание: я привык разрабатывать Drupal, поэтому я смог бы сделать многие из этих вещей довольно быстро, поскольку недавно я делал нечто подобное. Возможно, это не лучший выбор для вас.

1. В модуле я бы создал для него два типа контента, restaurant и menu_item.
2. Ресторан, вероятно, будет просто заголовком и другим полем, которое я бы использовал для пункта меню типы. Я не уверен, как бы я это сделал, это немного зависит от того, каким будет будущее проекта. Я мог бы выбрать не делать тип контента Ресторан или не делать с ним ничего особенного, а создать таблицу исключительно для упорядочивания типов пунктов меню.
3. Большая часть типов контента пунктов меню может быть выполнена через CCK, но я бы, вероятно, создал таблицу и настраиваемые поля для их упорядочивания (это то, что я делал несколько раз, поэтому у меня есть фрагмент для создания перетаскиваемой системы упорядочивания js, как CCK для упорядочивания полей) . Я мог бы также сам управлять ценами, если мне нужен лучший контроль в разных случаях, например, при проведении расчетов обмена и т. Д.
4. Для категорий я бы использовал таксономию (использование таксономии дает много дополнительных бонусов, таких как SEO) .
5. Я бы использовал ссылку на узел, чтобы привязать пункты меню к любому меню, в котором они должны быть.
6. Остальные поля пунктов меню - это просто текстовые поля, которые CCK отлично справился бы.
7. Я бы использовал node_api чтобы получить элементы меню для узлов ресторана, так что с темами вид узла ресторана будет отображением меню (если это основная функция, иначе я d создайте вкладку для меню и сохраните информацию о ресторане в представлении узла).
8. С помощью некоторого form_alter я бы создал систему заказа, которая была бы подключена к любой системе, которую я выберу для упорядочивания категорий.
9. Я мог бы позволить администраторам иметь возможность изменять порядок самих пунктов меню в отображении узла или создавать для него вкладку. Зависит от того, что хочет клиент.

Это немного сложно для разработчиков, так как многие из этих вещей нужно будет кодировать. Вы можете пойти очень далеко, просто используя cck и views, но я бы предпочел создать для этого модуль. Причина в том, что если клиент захочет это изменить через полгода или добавить дополнительные функции, мне может быть очень сложно это реализовать. Интеграция с cck и views может быть очень сложной и трудоемкой, поэтому, потратив немного больше времени, сделает его более гибким и расширяемым. Я также делал разные вещи, у которых есть общие основания, поэтому я мог бы C / P много кода, который я хорошо знаю, и просто настраивать его здесь и там для некоторых из этих вещей. Это также отчасти причина того, что я пошел по этому пути, поскольку использование только cck и views в любом случае не сэкономило бы мне столько времени

Мне пришлось сделать что-то очень похожее на это. Я решил это с помощью панелей, просмотров и cck. Я создал тип узла «ресторан» и тип узла «menu_item». таксономия menu_item задается с использованием определенного словаря. Я использовал панели для отображения меню для путей название ресторана / меню, затем views + cck, чтобы показать элементы в меню (я использовал ссылки на узлы, чтобы связать элементы с ресторанами). затем я сгруппировал представление по таксономии: поле термина.

Первая идея, которая пришла мне в голову, могла бы быть следующей:

• Тип содержимого еды с: названием (title), описанием (body) и ценой
• Тип содержимого ресторана с несколькими полями ссылок на узлы еды
• Словарь, связанный с едой, с такими терминами как напитки, коктейли, паста, .... (и я уверен, что есть модуль, который позволяет вам определять вес терминов таксономии)

Таким образом, вы можете хранить свои данные.

Для отображения вы можете использовать:

1. (лучший подход) пользовательский узел-restaurant.tpl.php, который создает отформатированную страницу, показывающую блюда, классифицированные по терминам таксономии (я уверен, что у вас есть прямой доступ к ссылающимся узлам через переменные шаблона...). Я собираюсь проверить это и сообщить вам)
2. (может быть сделано через панель администратора) Представление в блоке, размещенном в области "содержание", показывающее ссылающиеся узлы, отформатированные как таблица, сгруппированная по термину таксономии на словаре "категория еды". Вы можете получить текущий nid узла (используемый для фильтрации), используя аргументы.

Я рекомендую первый вариант, поскольку он более соответствует стандартам, быстрее в исполнении и может избежать некоторых возможных проблем, которые могут возникнуть при использовании способа views+block.