И все же не могу не спросить, зачем?
Меня такой подход заставляет писать код на js чище, собирать отдельные объекты и функции. И, по-моему, скрипты вида — не более чем макет, который для удобства работы следует отделить от жаваскрипта и стилей.
эм… у меня это реализуется так: приложения (в 95% случаев) работает и без яваскрипта. А яваскрипт сам по себе нужен только как часть пользовательского интерфейса, так что при компиляции шаблонов, если js файл для приложения существует, оно дописывает вызов в хеадере… короче больно хитрая система)) Но мне нравится)) А главное никакой мороки с подключением) кинул в папку js файлик mawebapp.js и готово) при загрузке одноименного приложения оно будет подключаться.
… если не будет очепятки в имени.
niggas in da habra
>class My_Controller_Plugin_Webinit extends Zend_Controller_Plugin_Abstract

Ужас…
Что испугало? Что Webinit лежит в library/My/Controller/Plugin/, аналогично Zend?
Вот это и «пугает» в ZF.
Никак в толк не возьму что вы имеете ввиду? Что тут ужасного?
У человека просто стереотипы. Прочитал в какой-нибудь умной книжке, что длинные имена это плохо и заучил это как непоколебимую истину, вместо того, чтобы своей головой подумать.
Достаточно человеку, знакомому с фреймворком, посмотреть на это объявление класса, и он поймет, что имел в виду разработчик кода, а также отчасти, чего ожидать от этого класса. Одной строкой. Страшно?
Тоже сталкивался с описанной проблемой. Подключал файлы вручную — пока такой подход устраивает, так как таких страниц штук 5-6.

Настоящая проблема возникла, когда кода на javascript стало так много, что там тоже нужно было организовывать все как-то в соответствии с MVC. И универсального решения пока не нашел.
А заголовок был многообещающий ("… MVC для Javascript ..."). (((
>javascript код максимально красивый при помощи библиотеки jQuery.
Когда идея овладевает массами, она становится материальной силой (с)
Но имхо если смотрите в сторону jQuery, м.б. имеет смысл уйти от программирования клиентской части на стороне сервера и заняться динамической загрузкой js-скриптов?
Да и вообще конструкция
$.data($.TRANSLATION, «Nice to see you!», '');
уродская (извините уж). Имхо лучше воткнуть эти данные в како-нибудь другое место. Например в метатеги, имена которых вообще м.б. произвольными. А уже на клиенте разбирать эти данные тем же $(document).ready…
По поводу первой части — немного недопонял. Если можно, растолкуйте поподробнее, что от этого изменится.

Конструкция и правда не блещет. Думаю, как организовать работу со словарем удобнее и так, чтобы не тормозить клиентскую часть.
>По поводу первой части — немного недопонял.
Первая и вторая — общие. В идеале (так как я этот идеал понимаю) серверное и клиентсткое программирование должны быть максимально развязаны. В HTML выводится не чистый js а инструкции для js (метатеги, специфические id, class)/ Все остальное (включая подгрузку необходимых js-библиотек) должно выполняться на стороне клиента.
С CSS конечно все сложнее.
Первый шаг я сделал. В отличие от Fesor несколько лишних казалось бы телодвижений ради разграничения кода меня не пугают. По поводу метатегов с инструкциями для js подумаю, благо есть где применить, может быть получится решение поизящнее. Спасибо за идею.

В идеале (так как я этот идеал понимаю) серверное и клиентсткое программирование должны быть максимально развязаны.

Всеми своими ложноножками за.

С CSS конечно все сложнее.

При динамической подгрузке придется либо весь стиль максимально описывать, либо организовывать js-код так, чтобы при создании новых элементов по необходимости подключались нужные стили уже в клиентсткой части. Если, к примеру, модуль calendar.js использует calendar.css с известным путем, то сам модуль должен попытаться подключить таблицу стилей при инициализации. Я вижу это как-то так.
>Если, к примеру, модуль calendar.js использует calendar.css
Я про это и сказал, что здесь готовый рецепт нельзя придумать. Если календарь покажется после нажатия пользоватлем кнопки/ссылки тут все нормально А если он должен отображаться исходно, то наверное не очень здорово тормозить отображение страницы за счет динамически подгружаемых CSS.
Советую привязать файлы скриптов не по имени экшена, а по имень файла вида, ведь именно для него они и существуют. Помните, что разные экшены могут использвать один и тот же вид (например, форма редактирования и добавления записей).

Жёстко подключая только один файл вы слегка облегчаете себе жизнь. Если страница имеет сложный клиентский интерфейс, тогда файлов по-хорошему будет много (склеивание в один, сжатие — это другой вопрос для production варианта). Идея высказанная выше про папку в таком случае намного лучше.
Спасибо, сразу об этом не подумал, следует немного видоизменить плагин. Потихоньку набираю мыслей на реализацию, попробую собрать все воедино и показать следующий вариант.
> defined('APPLICATION_PUBLIC_PATH') || define( 'APPLICATION_PUBLIC_FOLDER', dirname(__FILE__) );

Вы тут проверяете наличие одной константы, а дефайн делаете другой
Спасибо, поправил.
А вот интересно, путь, который предлагает ZendX_JQuery на практике не подходит для реальных проектов? Насколько я понимаю писать некоторый код можно непосредственно в контроллере на PHP, а не во view, что по-моему лучше для определенной логики (подготовки дынных для вывода), однако, в при таком подходе мы сильно ограничены запрограммированным в ZendX_JQuery функционалом. Кто-нибудь пользует?
упс, не ожидал, что это все-таки опубликуется. Удалить как-то можно? Активность на хабре стал проявлять недавно, не все еще мне известно…
Удалить нельзя, пользуйтесь кнопочкой «Предпросмотр» перед отправкой.
А вот интересно, путь, который предлагает ZendX_JQuery на практике не подходит для реальных проектов? Насколько я понимаю писать некоторый код можно непосредственно в контроллере на PHP, а не во view, что по-моему лучше для определенной логики. Плюс как раз решается проблема, которую отчасти пытался решить автор — подготовка данных к отображению из модели в определенном экшне. Однако, в при таком подходе мы сильно ограничены запрограммированным в ZendX_JQuery функционалом. Кто-нибудь пользует? Если да, то приходится ли дописывать javascript код руками?
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.