Expression Engine: когда использовать каналы, а когда не использовать?

Я все еще относительный новичок в Expression Engine как разработчик и пользователь. Я столкнулся с проблемой, что многие мои знания передаются мне пользователями, которые нашли способы выполнения задач, традиционно выполняемых разработчиками (например, библиотеки продуктов), используя систему каналов.

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

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

Я в основном подбираю чужую работу, но это не их вина, это была информация, которую им дали, поскольку они также были новичками в системе.

В любом другом проекте это будет настройка типа master-detail, события принадлежат местам проведения, я бы, вероятно, написал 2 настраиваемые таблицы, редакторы в области администрирования через модули, а затем использовал обычный пользовательский код на страницах для отображения и действия на них. info — таким образом я мог бы контролировать, что происходит, когда пользователь нажимает кнопку «Отправить».

Тем не менее, инициатор является опытным пользователем Expression Engine и проинструктировал предыдущего разработчика в стиле «о, просто поместите все это в каналы, а затем этот тег, этот тег и так далее».

Итак, я упускаю суть или я прав, что это не соответствует системе каналов, и когда вы должны использовать каналы, а когда нет?

Спасибо, друзья.


person JamesB    schedule 27.06.2012    source источник
comment
Возможно, это может помочь: train-ee.com/courseware /скринкасты/детали/ . Блог — это термин v 1.x для канала.   -  person Robert    schedule 28.06.2012


Ответы (2)


Этот вопрос очень гипотетичен, и каждый разработчик даст вам свой ответ, поскольку все зависит от требований и того, как работает этот разработчик EE.

По сути, ExpressionEngine позволяет вам подходить к сборке разными способами, ни один из них не является правильным или неправильным, хотя некоторые из них проще, некоторые сложнее, а некоторые просто глупы.

По сути, каналы — это группы «записей» данных — это может быть что угодно. Используя ваш пример, места проведения могут быть одним каналом с полями, созданными по теме (например, местоположение, размер, цена и т. д.). И еще один канал для событий с разными полями (например, дата, тип, место).

В канал можно вставить что угодно. Но данные об участниках лучше всего хранить в собственных функциях участников (хотя есть коммерческое дополнение, которое хранит данные участников в канале).

Вы ссылаетесь на предыдущий подход разработчиков — это могло быть связано с тем, что они использовали стороннее дополнение, которое требовало, чтобы данные хранились отдельно для каналов, или с отсутствием понимания наилучшего подхода. Или просто потому, что разработчик решил подойти именно так! Я подозреваю, что последний разработчик затем связал участника (место проведения) с записью (событием), чтобы связать событие с местом проведения. Базовая функциональность EE позволяет использовать связанные записи, что позволяет связать одну запись с другой (например, Event -> Venue) или использовать отличное дополнение Playa, поэтому такой подход на самом деле не нужен.

Лично я всегда буду хранить данные в каналах, а людей/участников — в собственных функциях членства (например, администратор, посетители сайта, клиенты и т. д.). Я бы создал надстройку (использующую собственные таблицы/данные) для хранения дополнительной информации только в том случае, если она выходит за рамки того, что может хранить EE.

person Peter Lewis    schedule 28.06.2012

Чтобы ответить на ваш практический вопрос (честно говоря, он расширяет сферу какими должны быть вопросы о переполнении стека): вам следует использовать канал для площадок и канал для событий, а поле «Место проведения» в записи «Событие» — это тип поля «Связанные записи», связанный с каналом «Места проведения». Это "стандартный" способ EE, наиболее похожий на традиционную схему базы данных.

person Derek Hogue    schedule 28.06.2012
comment
Спасибо вам обоим, я выбираю ответ Питера, так как он соответствует моей ситуации, я был брошен в этот проект в самую последнюю минуту без предварительного опыта, а не поклонник EE из-за хакерства, которое они сделали с серверной частью CI - биты кажутся пропавшими без вести. API также кажется очень незрелым, это нормально, говоря, что нужно размещать вещи в каналах - может быть, потому, что для этой цели уже создан редактор, но когда дело доходит до программного манипулирования ими в коде, не хватает так многого, что нужно разработчику, а документация ИМХО - это немного не хватает. Это платформа, которую я не буду указывать в своем портфолио. - person JamesB; 14.11.2012