Comments 25
И все же не могу не спросить, зачем?
Меня такой подход заставляет писать код на js чище, собирать отдельные объекты и функции. И, по-моему, скрипты вида — не более чем макет, который для удобства работы следует отделить от жаваскрипта и стилей.
эм… у меня это реализуется так: приложения (в 95% случаев) работает и без яваскрипта. А яваскрипт сам по себе нужен только как часть пользовательского интерфейса, так что при компиляции шаблонов, если js файл для приложения существует, оно дописывает вызов в хеадере… короче больно хитрая система)) Но мне нравится)) А главное никакой мороки с подключением) кинул в папку js файлик mawebapp.js и готово) при загрузке одноименного приложения оно будет подключаться.
>class My_Controller_Plugin_Webinit extends Zend_Controller_Plugin_Abstract
Ужас…
Ужас…
Что испугало? Что Webinit лежит в library/My/Controller/Plugin/, аналогично Zend?
Тоже сталкивался с описанной проблемой. Подключал файлы вручную — пока такой подход устраивает, так как таких страниц штук 5-6.
Настоящая проблема возникла, когда кода на javascript стало так много, что там тоже нужно было организовывать все как-то в соответствии с MVC. И универсального решения пока не нашел.
А заголовок был многообещающий ("… MVC для Javascript ..."). (((
Настоящая проблема возникла, когда кода на javascript стало так много, что там тоже нужно было организовывать все как-то в соответствии с MVC. И универсального решения пока не нашел.
А заголовок был многообещающий ("… MVC для Javascript ..."). (((
>javascript код максимально красивый при помощи библиотеки jQuery.
Когда идея овладевает массами, она становится материальной силой (с)
Но имхо если смотрите в сторону jQuery, м.б. имеет смысл уйти от программирования клиентской части на стороне сервера и заняться динамической загрузкой js-скриптов?
Да и вообще конструкция
$.data($.TRANSLATION, «Nice to see you!», '');
уродская (извините уж). Имхо лучше воткнуть эти данные в како-нибудь другое место. Например в метатеги, имена которых вообще м.б. произвольными. А уже на клиенте разбирать эти данные тем же $(document).ready…
Когда идея овладевает массами, она становится материальной силой (с)
Но имхо если смотрите в сторону jQuery, м.б. имеет смысл уйти от программирования клиентской части на стороне сервера и заняться динамической загрузкой js-скриптов?
Да и вообще конструкция
$.data($.TRANSLATION, «Nice to see you!», '');
уродская (извините уж). Имхо лучше воткнуть эти данные в како-нибудь другое место. Например в метатеги, имена которых вообще м.б. произвольными. А уже на клиенте разбирать эти данные тем же $(document).ready…
По поводу первой части — немного недопонял. Если можно, растолкуйте поподробнее, что от этого изменится.
Конструкция и правда не блещет. Думаю, как организовать работу со словарем удобнее и так, чтобы не тормозить клиентскую часть.
Конструкция и правда не блещет. Думаю, как организовать работу со словарем удобнее и так, чтобы не тормозить клиентскую часть.
>По поводу первой части — немного недопонял.
Первая и вторая — общие. В идеале (так как я этот идеал понимаю) серверное и клиентсткое программирование должны быть максимально развязаны. В HTML выводится не чистый js а инструкции для js (метатеги, специфические id, class)/ Все остальное (включая подгрузку необходимых js-библиотек) должно выполняться на стороне клиента.
С CSS конечно все сложнее.
Первая и вторая — общие. В идеале (так как я этот идеал понимаю) серверное и клиентсткое программирование должны быть максимально развязаны. В HTML выводится не чистый js а инструкции для js (метатеги, специфические id, class)/ Все остальное (включая подгрузку необходимых js-библиотек) должно выполняться на стороне клиента.
С CSS конечно все сложнее.
Первый шаг я сделал. В отличие от Fesor несколько лишних казалось бы телодвижений ради разграничения кода меня не пугают. По поводу метатегов с инструкциями для js подумаю, благо есть где применить, может быть получится решение поизящнее. Спасибо за идею.
Всеми своими ложноножками за.
При динамической подгрузке придется либо весь стиль максимально описывать, либо организовывать js-код так, чтобы при создании новых элементов по необходимости подключались нужные стили уже в клиентсткой части. Если, к примеру, модуль calendar.js использует calendar.css с известным путем, то сам модуль должен попытаться подключить таблицу стилей при инициализации. Я вижу это как-то так.
В идеале (так как я этот идеал понимаю) серверное и клиентсткое программирование должны быть максимально развязаны.
Всеми своими ложноножками за.
С CSS конечно все сложнее.
При динамической подгрузке придется либо весь стиль максимально описывать, либо организовывать js-код так, чтобы при создании новых элементов по необходимости подключались нужные стили уже в клиентсткой части. Если, к примеру, модуль calendar.js использует calendar.css с известным путем, то сам модуль должен попытаться подключить таблицу стилей при инициализации. Я вижу это как-то так.
>Если, к примеру, модуль calendar.js использует calendar.css
Я про это и сказал, что здесь готовый рецепт нельзя придумать. Если календарь покажется после нажатия пользоватлем кнопки/ссылки тут все нормально А если он должен отображаться исходно, то наверное не очень здорово тормозить отображение страницы за счет динамически подгружаемых CSS.
Я про это и сказал, что здесь готовый рецепт нельзя придумать. Если календарь покажется после нажатия пользоватлем кнопки/ссылки тут все нормально А если он должен отображаться исходно, то наверное не очень здорово тормозить отображение страницы за счет динамически подгружаемых CSS.
Советую привязать файлы скриптов не по имени экшена, а по имень файла вида, ведь именно для него они и существуют. Помните, что разные экшены могут использвать один и тот же вид (например, форма редактирования и добавления записей).
Жёстко подключая только один файл вы слегка облегчаете себе жизнь. Если страница имеет сложный клиентский интерфейс, тогда файлов по-хорошему будет много (склеивание в один, сжатие — это другой вопрос для production варианта). Идея высказанная выше про папку в таком случае намного лучше.
Жёстко подключая только один файл вы слегка облегчаете себе жизнь. Если страница имеет сложный клиентский интерфейс, тогда файлов по-хорошему будет много (склеивание в один, сжатие — это другой вопрос для production варианта). Идея высказанная выше про папку в таком случае намного лучше.
> defined('APPLICATION_PUBLIC_PATH') || define( 'APPLICATION_PUBLIC_FOLDER', dirname(__FILE__) );
Вы тут проверяете наличие одной константы, а дефайн делаете другой
Вы тут проверяете наличие одной константы, а дефайн делаете другой
А вот интересно, путь, который предлагает ZendX_JQuery на практике не подходит для реальных проектов? Насколько я понимаю писать некоторый код можно непосредственно в контроллере на PHP, а не во view, что по-моему лучше для определенной логики (подготовки дынных для вывода), однако, в при таком подходе мы сильно ограничены запрограммированным в ZendX_JQuery функционалом. Кто-нибудь пользует?
А вот интересно, путь, который предлагает ZendX_JQuery на практике не подходит для реальных проектов? Насколько я понимаю писать некоторый код можно непосредственно в контроллере на PHP, а не во view, что по-моему лучше для определенной логики. Плюс как раз решается проблема, которую отчасти пытался решить автор — подготовка данных к отображению из модели в определенном экшне. Однако, в при таком подходе мы сильно ограничены запрограммированным в ZendX_JQuery функционалом. Кто-нибудь пользует? Если да, то приходится ли дописывать javascript код руками?
Sign up to leave a comment.
Zend Framework: стремимся к MVC для Javascript, CSS