TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Подключение сприптов
  • Вот смотрю на посты, и немного не понимаю, люди подключают js в контроллере, и потом передают в view. В чем прелесть так ограничивать возможность view. Если при изменении дизайна, нужно будет править еще и контроллеры. А так отдал каталог views верстальщику на растерзание, и пусть делает что хочет.

  • requirejs и проблем минимум.

  • @misterx передача данных в assets модуль должна производится в контроллере или (желательно) в модели, но никак не во view или вам как и мне не нравиться что названия файлов прописываются прямо в контроллере, а не загружаются ,например, из конфига?

    @Ramallah это что за зверь?

  • Дело в том, что контроллер выполняет бизнес логику, а за представления отвечает view, потому, если навязать js и css в контроллере (а это относится к отображению), мы сильно ограничим views. В модели подключать js и css -- это вообще извините маразм, т.к., модель используется для работы с данными. Потому подключение всес скриптов, должно быть в view.

  • Мне тоже не нравится когда мешают браузерное и серверное. У меня теперь backbone+require, а сервер отдает данные в json, и шаблонов нет. А нет, один есть, главный =)

  • @misterx

    Дело в том, что контроллер выполняет бизнес логику

    Бизнес логика в моделях, исходя из определения mvc

    В модели подключать js и css -- это вообще извините маразм, т.к., модель используется для работы с данными.

    a js и css по вашему не данные?

    Обобщая выше сказанное, контроллер передает в модель(assets модуль) ряд параметров(например, URL или ID страницы) и получает обработанный результат (например, итоговые URL'ы css\js файлов), который передается в вид, a вид, в свою очередь, его отображает (теги с переданными ссылыками).

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

    Из вики, про MVC, если вы хотите по определению: Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).

    Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции.

    JS и CSS не данные, от которых зависит логика поведения приложения. Оно нигде не используется кроме как в view.

  • @misterx, полностью с вами согласен, но у меня были случаи, когда верстка была до такой степени корявой, что приходилось выкручиваться через контроллер, чтобы не переделывать движок. Вариант переделать верстку, или сделать изначально нормально в той конторке, где я работал, не рассматривался.

    А так подключения во вьюшке вполне достаточно, в крайних случаях, как написал @Ramallah, RequireJs в помощь)

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

  • misterx: Из вики, про MVC, если вы хотите по определению: Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида).

    В Вашем же случае логика оказывается в визуализации.

    misterx: JS и CSS не данные, от которых зависит логика поведения приложения.

    Тем не менее эти данные надо каким-то образом получить из модели. а mvc подразумевает обмен между моделью и видом через контроллер

  • Какая логика в визуализации, прочитайте http://ru.wikipedia.org/wiki/Model-View-Controller

    Вы походу все напутали. В модели, лежат те данные которые нужны для работы приложения, но никак не для представления.

    Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.

    В вашем случае, вы содержите данные о визуализации, поскольку js и css напрямую относятся, только к визуализации.

    @DimkOf Я немного не понимаю, как верстальщик может заставить программиста вписывать стили через серверную часть.

    Я, например, верстальщику даю доступ к каталогу с шаблонами, в основном на каждый контроллер/экшн свой шаблон, в которые передаются данные. Архитектуру шаблонов оставляю на рассмотрение верстальщику. У него в шаблон приходят данные приложения, а как он их будет выводить, это его проблема.

  • misterx: В вашем случае, вы содержите данные о визуализации, поскольку js и css напрямую относятся, только к визуализации.

    В моем случае контроллер передает в модель массив ссылок на js\css, полученный из конфига, а потом передает полученные от модели ссылки на итоговые js\css файлы в вид. В виде на основании данных ссылок строятся теги. Никакой визуализации в модели нет, как и в контроллере

    Можно взглянуть на Ваш пример реализации?

  • Могу набросать, т.к. нигде не выкладывал.

  • @misterx набросай, а то слишком абстрактаное обсуждение получается, я тогда заодно свой вариант выложу

  • Эммм... js/css прогонять через контроллер - еще пойму (ну, например, чтобы на выходе получить сжатые 2-3 файла). Но через модель - никогда не пойму... С какого js/css участвуют в бизнес-логике? Как они вообще относятся к данным?

    И еще не понимаю, для чего на разных страницах грузить разные js/css-файлы? Почему нельзя их грузить на каждой и кешировать у клиента?

  • Сжатие скриптов делаю перед деплоем, внешней тулзой. А в шаблоне проверка, если продакшен или стейдж подключать такой-то сжатый файл, если дев подключаю все без сжатия. По поводу разных скриптов, иногда бывают случаи что нужно подключить другие джски, но все решается в view

  • @aktuba Assets классы это те же модели

  • С чего вдруг? о_О Честно - не пользуюсь assets, но из изученного ни один не напоминает даже близко модели. Хелперы - да.

  • @aktuba Модель это класс содержащий данные и имеющий методы для работы с ними, чем же assets под данное определение не подходит?

  • Тем, что:

    1. скрипты не являются данными, а скорее управляющими методами view. Чаще всего они отвечают за действия во вьюхах. Скрипты не работают с данными бизнес-логики, максимум дают указания контроллеру выполнить определенное действие. Верно?
    2. стили не являются данными, т.к. полностью отвечают за внешний вид. Т.е., работа с данными бизнес-логики не завязана на отображение результатов работы с этими данными. В любой момент можно поменять шаблон и бизнес-логика не должна пострадать от этого, верно?
    3. Решение, какие стили и скрипты должны быть подключены к текущему внешнему виду не относится к бизнес-логике. На 100% относится к View, т.к. результат влияет на внешний вид. Все правильно?
    4. Assets не влияет на данные, а влияет на результат отображения, что видно по п.3. Соответственно, к моделям отнесен не может быть. Только к хелперам, т.к. является помошником отображения.

    P.S.: js/css не могут быть "данными" по дефолту. Они не изменяемы в процессе работы программы, т.е. они либо часть программы, либо константы (что тоже является частью программы).

  • @aktuba По моему ты не понимаешь разницу между моделью и хэлпером, а также что такое бизнес-логика. Mногое также зависит от конкретной реализации Assets модуля.

  • Ну пусть будет так).

  • @WinterSilence Давай конкретный пример, когда требуется js/css прогонять через модель. Что там с ними происходит, и что на выходе.

    Я понимаю, иногда требуется динамические данные от модели хранить в js/xml и тд. И то, в идеале, модель не должна знать о формате хранения таких данных, а отдавать тупо массив/итератор и тд, то есть сырые данные.

  • Товарищи, не надо делать из MVC культа. Вам дали удобную парадигму организации файлов и классов, так юзайте её как фундамент, а не как клетку.

    Посмотрите Laravel и почитайте "From Apprentice To Artisan - Advanced Architecture With Laravel 4": https://leanpub.com/laravel Тейлор там, например, советует - попробуйте ради эксперимента удалить папку models и написать достаточно сложный аппликейшн без неё. Сначала будет ломка, но когда вы перешагнете через старые привычки и проявите фантазию и скилл программиста, вы удивитесь, насколько красивым, понятным и расширяемым получится приложение.

  • @biakaveron я уже писал выше, если конкретнее: каждая страница состоит из разных блоков, каждый блок имеет свой набор js\css файлов, на выходе получаем ссылки на js\css файлы, состоящие из минимизированных и объединенных js\css файлов блоков. кроме этого удаляются дубли, компилируются less/sass, работа с кешированием данных.

  • @WinterSilence вот он http://www.requirejs.org/

    ИМХО, assets-модули удобны в начале большоего проекта, но потом в такое УГ перерастает. В маленьких проектах тоже можно использовать. Ведь сегодня яваскрипта порою больше выходит чем кода в контроллерах.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion