Новичок в CodeIgniter - многоразовый просмотр кода, куда идти?(Helper?) - PullRequest
4 голосов
/ 21 марта 2011

Я новичок в CodeIgniter, который все еще изо всех сил пытается понять, как использовать идеологию MVC максимально аккуратно.

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

  • Панель голосования
  • Следить / Отписаться панель
  • Панель входа / выхода
  • Код для проверки входа пользователя в систему и т. Д.

Мне интересно, куда поместить этот код, чтобы он мог быть унифицирован? Я думаю, что помощник это путь? Если я объявлю помощника в контроллере, его можно вызвать из соответствующего представления, верно?

Некоторые элементы являются динамическими - например, кнопка «следовать / отменить подписку» - необходимо проверить, следует ли вы уже за пользователем или нет, и отобразить соответствующую кнопку, для которой потребуется проверить модель. Теперь я имею в виду, что вся логика находится в контроллере, и она возвращает соответствующую кнопку, но кажется странным возвращать сформированный html-код в возврате контроллера. Должно ли это быть больше похоже на:

  • Контроллер проверяет, следите ли вы за кем-либо
  • контроллер передает логическое значение в представление
  • представление вызывает помощника с этим значением, чтобы нарисовать соответствующую кнопку

Кроме того, в качестве дополнительного вопроса я выполнял цикл циклов по массивам mysql в циклах foreach для обработки результатов mysql, возвращаемых из представления. Кажется, что мои взгляды становятся несколько сложными, но я не могу придумать другого способа сделать это, хотя, возможно, это должно быть сделано и в другом помощнике?

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

Ответы [ 3 ]

0 голосов
/ 21 марта 2011

Что касается обработки пользовательских входов в систему, вы, вероятно, захотите использовать статический класс и шаблон проектирования Singleton, который позволит вам проверить, вошел ли конкретный пользователь в приложение или нет. Здесь есть хороший учебник http://www.phpandstuff.com/articles/codeigniter-doctrine-scratch-day-4-user-login

Загрузка помощника, я не верю, что загрузка его в ваш контроллер автоматически загрузит его в вашем представлении. Я думаю, что вы должны повторно загрузить помощник в вашем файле представления, или вы должны автоматически загрузить помощник. (не могу вспомнить, но я уверен).

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

0 голосов
/ 21 марта 2011

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

Помощник - имеет функции без класса. Таким образом, отдельная функция или группа функций может быть помещена в файл и сохранена в качестве помощника.

Например, я использовал помощника со стандартными функциями обработки форм для NewsPapair вместо статического класса. Но это не самая лучшая практика. Я сделал это так, потому что у меня уже были функции из предыдущего проекта.

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

0 голосов
/ 21 марта 2011

Помощники, безусловно, являются одним из способов модульности всего, что не DRY .Другое - использовать частичные виды.CodeIgniter выглядит так, как будто он поддерживает частичные представления. Вот хорошая разбивка - не специфичная для PHP, но обсуждение должно быть агностичным.

...