Хорошо, дай мне посмотреть, смогу ли я разобрать это на кусочки и помочь тебе.
Во-первых Непонятна последовательность вашей терминологии, поэтому я собираюсь создать небольшой глоссарий здесь, так что я уверен, что вы понимаете, что я имею в виду:
- Жизненный цикл запроса Полный запрос HTTP через ваше приложение. Вызовы Ajax - это жизненные циклы, загрузки страниц - это жизненные циклы, после отправки документа и закрытия соединения жизненный цикл заканчивается.
- Контроллер Код, ответственный за контроль выполнения запроса lifecylce через ваш сайт.
- Просмотр Фактический вывод код для любой страницы / запроса. Это код в
application/views, и он используется практически каждый раз, когда существует жизненный цикл запроса (кроме, возможно, перенаправлений и ajax).
- Код клиента Логика Javascript, возникающая после загрузки страницы. Ajax-вызовы совершаются по клиентскому коду .
Я собираюсь ответить на ваши вопросы немного не в порядке, поэтому терпите меня:
Это выдвигает мой первый, смехотворно простой вопрос. Это нормально? Одна из моих главных проблем, конечно же, это пользователи, у которых не включен javascript; приложение просто не работает. Я читал о постепенном ухудшении и прогрессивном улучшении, но я просто не уверен, выполнимо ли это приложение без JS.
Дело в том, что в том, что Javascript является довольно неотъемлемой частью того, что мы сейчас называем «веб-приложениями». Разница между веб-приложением и веб-сайтом заключается в том, что первое интеллектуально. Большинство сайтов обычно просто обрабатывают запросы и отображают соответствующие данные, однако приложения обычно принимают решения, обновляют состояние системы и изменяют выходные данные на основе входных данных.
То, что вы создаете, я бы классифицировал как веб-приложение .
Я не верю в наши дни и в эпоху HTML5 (вроде) с сегодняшними Facebook и youtube, что необоснованно требовать использования javascript для использования веб-приложения.
Люди, которые отключают свой javascript в наши дни, делают это через плагины, такие как AdBlock и NoScript, которые обычно позволяют вам выборочно отключать вещи. Лучший способ борьбы с этим - разделить ваш javascript на легко узнаваемые компоненты, чтобы пользователи знали , какие скрипты разрешены.
Пример * * тысяча шестьдесят-одна
Site.js - Отвечает за функционирование и работу сайта. Ads.js - Ответственный за вашу рекламу
Вы не можете помешать людям блокировать ваши объявления, если вы стараетесь, чтобы они просто не пользовались вашим сервисом. (При условии, что вы планируете рекламу)
Итак, постарайтесь изящно снизить производительность, чтобы информировать пользователей о том, что для работы вашего приложения требуется JavaScript, вы даже можете сообщить им, какие файлы необходимы для облегчения процесса.
Настоящая страница «Планировщик» - это совсем другая история. Одна из первых вещей, которые меня интересуют, это то, могу ли я использовать / вызывать функции из представления. Если я буду следовать рекомендациям MVC, я скажу, что не могу. Итак, сейчас я собираю все данные в массивах $ data на моем контроллере, а затем выводю их через вызовы jQuery AJAX прямо на мою веб-страницу.
Ключ, который нужно запомнить: MVC - это рекомендация , а не правило. Хотя лучше придерживаться вашей системы, вы должны применять ее там, где это уместно. Вероятно, вам не следует извлекать записи базы данных из вашего представления , но при представлении в некоторых готовых ситуациях у вас остается два варианта:
- Немного сломайте парадигму там, где это имеет смысл (по уважительной причине)
- Рефакторинг вашей системы в соответствии с парадигмой
Хороший пример: Многократно используемые блоки виджетов, такие как облако тегов или блок последних сообщений
Суть в том, что вам, вероятно, не нужно постоянно предоставлять данные для $this->load->vars(...) или даже хуже для каждого $this->load->view в каждой функции контроллера.
Один из подходов состоит в том, чтобы перестроить вашу систему, чтобы у вас была общая библиотека тем, отвечающая за сбор общей информации и ее предоставление, а затем передачу данных вашего представления ($this->load->view("someview", array(),true) отобразит ваш вид в виде строки вместо страницы).
Другой подход заключается в разработке специального представления, которое имеет простую работу, с использованием модели, загружающей соответствующие данные (если возможно, кэш) и отображающей их. Как виджет, или самодостаточная вещь. Это нарушает MVC , но вам нужно изучить причины, по которым мы используем MVC. Ключ заключается в том, что представление не должно отвечать за реализацию, таким образом вы можете поменять представление, и логика контроллера останется неизменной. Это относится? это может быть компонент с высокой степенью реализации, контроллер может не знать, что ему нужна эта информация. Поэтому, если вы держите ручку на ней и помечаете ее, чтобы помнить, что она несет ответственность за себя, вы должны быть в состоянии приспособить ее просто отлично.
Еще одна вещь, в которой я не уверен (с точки зрения AJAX), это то, что у меня есть два разных AJAX-вызова на $ (document) .ready, а затем еще четыре, когда пользователь нажимает на разные элементы. Меня также беспокоит, что jQuery .html () на самом деле не помещает содержимое в мои html-теги (при просмотре исходного кода).
Похоже, вы пытаетесь сделать слишком много в коде клиента . Может ли любой из этих вызовов ajax @ start быть предоставлен представлением ?
Четыре вызова ajax, когда пользователь нажимает на что-нибудь? Большинство кликов представляют одно действие, обычно достаточно одного ajax, может быть двух, если вам нужно обработать ответ и запросить больше информации, но редко больше.
$.fn.html(...) в jQuery помещает первый параметр внутри выбранного элемента. Если вы хотите заменить HTML-код всей страницы (не рекомендуется, никогда ... это должна быть загрузка страницы). Вы бы назвали это:
var theHtmlToPutInPage = "... whatever ...";
$("body").html(theHtmlToPutInPage);
Моя главная проблема, в которой я застрял сейчас, - это часть дня. У меня есть заголовки таблиц «Горе, 20 апреля», но под ними мне нужны мои реальные события. Я не уверен, что будет лучшим подходом к созданию этой функции. Должен ли я положить его в стол? Но тогда как бы я поместил определенные события в нужное место? Пока все, чего я достиг, - это функция, которая выводит все события за определенный день в массив, например так:
Есть много подходов к этой проблеме. Вы могли бы построить все это как большую таблицу временных блоков, но это может привести к путанице. Кроме того, таблицы противны , Там есть много хорошо написано статей о том, когда и где использовать таблицы.
Вы можете настроить визуалы как единую сетку с помощью CSS Divs и перевести встречи поверх, используя position: absolute и управляя из кода клиента (javascript).
Это довольно сложная часть вашего проекта, есть много ответов, и у меня нет времени, чтобы по-настоящему углубиться в какие-либо решения, вам просто нужно создать прототип и поэкспериментировать.
Я готов предоставить ссылку на мой исходный код (github), если кто-нибудь захочет взглянуть на мой беспорядок и, возможно, попытаться снова поставить меня на правильный путь. Возможно, Я все еще на правильном пути; Я просто так не чувствую. Я застрял в части показа событий, и я просто чувствую себя ужасно, потому что я не доволен тем, что я написал (хотя большая часть этого работает, на данный момент).
Я бы с удовольствием посмотрел и дал предложения, так как я уверен, что некоторые другие здесь тоже.
Поскольку сейчас я нахожусь на пасхальном перерыве, я не могу связаться с моим учителем в течение еще одной недели, поэтому я готов предоставить вознаграждение в 100-150 представителей за хороший, полезный ответ на этот огромный спор / вопрос. .
Обычно для правильного ответа на ваш вопрос следует использовать щедрость. Такие вещи заставляют людей углубляться (как, возможно, этот ответ, теперь он становится мега длинным).
Вы можете предложить вознаграждение, это ваша репутация, однако не думайте, что вы должны предлагать вознаграждение. Если этот ответ удовлетворительный (или любой другой, который может опубликовать кто-то другой, простого принятия ответа должно быть более чем достаточно).
Резюме и заключительные мысли
Хорошо, поэтому в процессе написания этого чудовищного ответа (он еще считается новеллой?), Я думаю, что я, возможно, сделал вывод, где вы могли ошибаться. Это может быть сделано по замыслу, но может быть случайным.
Я думаю, что вы, возможно, ошибочно принимаете представление о клиентском коде. Когда мы говорим о MVC, мы не имеем в виду, что все это должно быть загружено через ajax, а представление - это javascript & dom, работающий в браузере клиента.
Если это не так, тогда, пожалуйста, не обращайте внимания на последний абзац.
Это действительно звучит так, как будто вы ошиблись в оценке ответственности. Похоже, вы ставите слишком много своего приложения на javascript. Загрузка страниц - не дьявол, ajax моден, но часто может быть Too Much . Вы должны найти подходящую для вашего приложения. Похоже, что вы могли бы выиграть, упростив свои проблемы, взяв на себя большую ответственность за представление вместо кода клиента .
Я надеюсь, что этот ответ помог вам, извините, что я так долго постил это, я видел ваш вопрос, когда вы его опубликовали, но тогда у меня не было времени углубиться в подробности.