Хотя до запуска моего первого сайта на Discourse (замена рассылки, которую я вёл 30 лет), вероятно, осталось ещё две недели, я уже думаю о другом возможном проекте — переносе своего блога о кулинарии и выпечке с WordPress/BBPress на Discourse.
Для этого мне нужен способ распознавать рецепты и изменять их форматирование и печать.
Похоже, что теги тем — это правильный подход для маркировки новой темы как содержащей рецепт в первом посте (последующие сообщения будут комментариями, а не полными рецептами), но, кажется, нет способа принудительно добавить тег (например, «recipe») в поле тегов. Я также рассматриваю использование поля тегов для указания типа рецепта (хлеб, десерт, мясо и т. д.), чтобы рецепт мог иметь несколько тегов, например: recipe dessert.
Печать — это отдельный вопрос. Я уже решил, что для реализации этой функции мне потребуется создать плагин, который даст Discourse больший контроль над печатью выбранных сообщений из темы. Форматирование поста с тегом рецепта (первого поста) для печати, вероятно, станет второй задачей. Мне, вероятно, ещё несколько месяцев потребуется, чтобы освоить достаточно Ruby для того, чтобы даже подумать о решении этой задачи.
Но хватит мечтать. Мой вопрос сейчас: можно ли принудительно добавить тег (например, «recipe») в новую тему в категории (например, «рецепты»), чтобы пользователю не нужно было выбирать его вручную и чтобы он не мог его удалить?
Я не уверен в вашем конкретном случае использования, но принудительное применение одного и того же тега ко всем темам в категории может оказаться избыточным.
Хотя с помощью текущих настроек нельзя предварительно заполнить тег для категории, это можно реализовать через компонент темы или плагин.
Без дополнительной кастомизации для вашего случая могут подойти несколько вариантов:
Настройте параметр «Минимальное количество тегов, требуемых в теме:» для категории и добавьте «группу обязательных тегов» к этой категории.
Таким образом, вы можете задать несколько тегов для категории, например: хлеб, десерт, мясо и т. д. — пользователи не смогут создать тему, не выбрав хотя бы один (или несколько) тегов.
Настройте автоматическое проставление тегов на основе слова или фразы, которые часто встречаются в рецептах. Это можно сделать в разделе admin/customize/watched_words.
Такой подход может потребовать некоторых проб и ошибок и не всегда будет идеальным. Если вы находитесь в США, это немного проще, так как в имперской системе мер есть уникальные единицы измерения. В большинстве рецептов, например, упоминаются ч. л. (tsp) или ст. л. (tbsp). Другие фразы, которые приходят на ум и довольно характерны для рецептов, могут включать разогреть духовку, смесительная миска, обжаривать и так далее.
На самом деле, мне бы скорее хотелось иметь отдельное поле в публикации с пометкой «это рецепт, отформатируйте соответствующим образом», чтобы теги можно было использовать для других, более ориентированных на пользователя целей, как мы оба уже показали. Однако пока я не уверен, как это реализовать. Я знаю, что существуют способы создания пользовательских полей для постов и тем, но я всё ещё изучаю, как к ним получить доступ или как их использовать.
Хотя я считаю, что в первую очередь метка для форматирования рецептов должна ставиться на ведущем сообщении в теме, теоретически это может применяться и в других случаях. Более того, могут быть и другие сценарии использования, когда нужно пометить пост для специального форматирования, выходящие за рамки моего кулинарного блога: помеченный пост не обязательно должен быть ведущим в теме или находиться в какой-то конкретной категории. И обобщение такого подхода могло бы иметь более широкое применение.
Детали формулировки рецептов — это отдельная сложная тема. В идеале мне бы хотелось структурированный формат, чтобы я мог выделить отдельные поля для ингредиента, единицы измерения и количества, желательно таким образом, чтобы можно было подключать другие базы данных с информацией о питательной ценности ингредиентов, ценах, запасах и т. д. Также указание общего выхода позволило бы масштабировать рецепт вверх или вниз. Несколько других кулинарных сайтов уже реализуют подобное, но, по моему мнению, в них отсутствуют функции, которые я хотел бы видеть и которые, уверен, нужны и сообществу пекарей. Вопрос о том, можно ли реализовать всё это в структуре данных Discourse, — это отдельная тема. (Но моё первое впечатление таково, что сделать это в Discourse может быть проще, чем в WordPress или в собственной системе с нуля, поскольку вы уже создали множество необходимых поддерживающих структур.)
Вы можете использовать TopicCustomField в плагине, но набор тегов, доступных только для сотрудников, или принудительный для всех пользователей, будет проще поддерживать. Также, не могли бы вы просто создать набор категорий для рецептов, чтобы применять это форматирование ко всей категории? Это кажется самым простым решением вопроса «какие темы являются рецептами».
Это сработало бы для моего конкретного случая, но я пытаюсь мыслить наперёд, создавая плагин, который имел бы более общую ценность. Что имеет больше смысла:
Я хочу, чтобы эта категория имела отдельное специальное форматирование
Я хочу, чтобы эта тема имела отдельное специальное форматирование
Я хочу, чтобы этот пост имел отдельное специальное форматирование
Какая-то комбинация вышеперечисленного, например, эта категория может использовать специальное форматирование в некоторых своих темах и/или постах, или эта тема может использовать специальное форматирование в некоторых своих постах
Я уверен, что пока недостаточно знаю о Discourse/Ruby, чтобы сделать что-то существенное, не говоря уже о том, чтобы делать это ПРАВИЛЬНЫМ способом, поэтому, возможно, работа над моим конкретным случаем станет для меня хорошим стартом. Но исторически, на проектах, над которыми я работал за последние 40 лет, как только кто-то находит упрощённый способ сделать что-то, он становится менее заинтересованным в более обобщённом подходе.
Это не совсем то, что я искал, но, думаю, вам лучше сосредоточиться на решении вашей реальной проблемы, а не тех, которые вы придумываете.
Это будет непросто, хотя можно создать плагин, который добавлял бы PostCustomField и включал его в сериализатор.
Просто решив, что у вас будут категории, содержащие только рецепты и требующие специального форматирования, вы покрываете подавляющее большинство случаев использования. Ещё один способ — принудительное использование набора тегов; это немного более капризно, но также практически не требует поддержки кода.
Я ценю ваши предложения и рекомендации. Новички — это действительно боль, не так ли? (Как я уже говорил в другом посте в другой теме, я пока не знаю, чего не знаю.)
Мой подход к системному анализу за годы работы заключался в том, чтобы при составлении списка пожеланий попытаться предвидеть как можно больше вещей, а затем посмотреть, сколько из них я решу, что мне либо не нужны, либо я не знаю, как их реализовать. Этот подход хорошо мне служил.
Единственная проблема, с которой я столкнулся при использовании тегов для этой цели, заключается в том, что кто-то может применить этот тег к теме, где он неуместен. Конечно, если я скажу: «Тег форматирования применяется только тогда, когда этот тег присутствует в теме в категории X», этого может быть достаточно для меня.
И ещё я подумал, что если тег форматирования необязателен, пользователи смогут создавать темы в этой категории без специального форматирования. Я пока не решил, хорошо это или плохо.
