Понимаете, если нет прокладки между рулём и сиденьем, которая будет страховать приложение от изменений снаружи в обязательном порядке, то выходит, что это просто «красивая обёртка над синглтоном» со списком хэндлеров. Ради чего вообще использовать распределённую систему с изолированными компонентами?
Вы сказали что враппер (интерфейс) — пустой перевод байт. Нет. Это одна из составляющих стабильности и успеха.
Но для _старта_ или _быстрой_сборки_ можно использовать прозрачное проксирование методов внешнего ресурса через интерфейс (но он должен быть с самомго начала). Опционально должно быть «исключение» интерфейса, а не его включения.
Но это всё теория. Если мы задумываемся о использовании этих концепций, значит у нас уже можно разбить систему на составляющие, которые со старта дожны быть изолированными.
Мне кажется в описанных perl-реализациях DI (как пример) есть концептуальная ошибка. Пусть у нас есть приложение (MyApp) и мы хотим в него внедрить внешний ресурс — например хэндлер к бд (db_handler, экземпляр DB) или к логгеру (logger_handler, экземпляр Log), с последующей возможностью подменить любой из хэндлеров (мы любим тесты). То при передачи в MyApp хэндлеров db_handler и logger_handler получится, что мы передаём непосредственно экземпляр класса DB и Log. Вот тут и кроется фундаментальная ошибка. При замене DB на DB2 мы будем обязаны реализовать в классе DB2 методы с точно таким же функционалом как в DB. То есть «свобода выбора» призрачная.
А что нужно? Как хороший пример — реализация в java. Я не владею этим языком, но изучение темы в сети дало вот что. Между приложением MyApp и классами DB и Log должен быть «интерфейс». Пусть у нас это будут iDB и iLog соответсвенно. Пусть в нашем приложении от Log необходим только метод error. Тогда интерфейс iLog должен иметь алиас error который вызывает Log->error или Log2->i_am_error в зависимости от того, какой внешний класс нам нужен. Я опустил, что интерфес так же должен управлять передачей аргументов по установленным правилам.
И вот теперь мое приложение MyApp будет использовать систему логирования или записи в БД независимо от реализации классов. Приложение будет использовать интерфейс, который гарантирует наличие необходимых методов.
У нас в perl например Bread::Board (http://search.cpan.org/dist/Bread-Board/) так же передаёт непосредственно хэндлеры внешних классов DB и Log в приложение. Это вроде как не совсем то, что нужно.
Может быть потому, что нет подобных реализаций и не используют?
Именно для более удобного обмена данными с менеджером. Он сам по себе очень туп, и работает. Немного логики в его работу не повредит, а польза какая-никакая есть.
SSI в принципе работает достаточно быстро. НО, некоторые господа забывают одну прекрасную вещь. Разбив свою страницу на блоки, которые например не кэшируются, или кэшируются на очень маленькое время, подключая их через virtual, нужно помнить, что это всё подзапросы. То есть, если на вашей странице («mysite.ru/main/») есть блок с профайлом пользователя (инклуд virtual="/userprfile/?id=123"), и блок последние комментарии пользователя (инклуд virtual="/lastcomment/?userid=123"), которые вы не кэшируете по тем или иным причинам, в результате выполнится три запроса к вашему скрипту обработчику.
В логах так и увидите
"/userprfile/?id=123"
"/lastcomment/?userid=123"
«mysite.ru/main/»
И, если вы установили в глобальный обработчик функцию проверки аутентификации, она выполнится три раза. Вы на один запрос пользователя будете его авторизовывать три раза.
Нужно очень внимательно смотреть на то, что вы подключаете как SSI. Такая вот горе оптимизация, ведет к тому, что вы усложняете работу вашего движка/скрипта…
Запись list.3 меня вводит в ступор, это некрасиво.
Ну скажем что это еще не самое страшное в жизни. Но при этом все же, вот как в примере, есть массив элементов, и нужен только конкретный элемент. Озадачиться обработкой данной ситуации в контроллере, или дать таки возможность обращаться к элементам массива по индексу?
В пункте 2.2 я написал, что запись почти все ЯП так или иначе поддерживают большиство операторов, отличия лишь в написании. Значит в шаблоне нужно будет использовать какой-то оговоренный синтаксис операторов, который парсером будет транслироваться в оператор заданного яп.
4. Инклуды
<!-- Вставить в шаблон инклуд nameinclude -->
% nameinclude %
<!-- Вставить в шаблон инклуд tpl_comments, передать в качестве текущего объекта, объект по адресу source.comment_data -->
% tpl_comments => source.comment_data %
В первом случае мы вставляем инклуд nameinclude, в качестве текущего объекта, будет объект, в контексте которого идет вызов инклуда. Во втором случае текущим объектом в инклуде tpl_comments будет выступать объект source.comment_data
Если мне надо изменить входящие данные — я сделаю это в контроллере. Если целесообразнее сделать в данном случае срез, я сделаю срез, если надо сделать очень сложные и трудоемкие выборки — сделаю в контроллере. Если надо отфильтровать по простому условию из 30 элементов всего 10 — я сделаю это в шаблоне. Вариантов масса.
Второй абзац не понял, но думается вы хотите что-то сказать, связанное с xslt. От того, что выборка определенных элементов производится по какому то признаку, и проход по ним для вас прозрачен, это не отменяет итерации этих элементов.
2. Как отметил в топике, в javascript нет оператора unless. Стоит ли его реализовать в шаблоне?
5. Статья на хабре про наследование в Django: habrahabr.ru/blogs/django/23132/
Описать тривиальные конструкции нужно для того, чтобы обозначить отправные точки для дальнейшего обсуждения, и поинтересноваться, может стоит добавить что-то еще?
Да, уже понял что неправильно выразился. То, что конструкции шаблонизатора обрамлены процентами, это просто в качестве примера, чтобы отвлечь от разделителей своё внимание…
Наверное стоило их совсем убрать из примеров…
Как ни странно, результатом можно увидеть не только очередной шаблонизатор. Есть необходимость в наличии рекомендаций, свода правил, которыми бы руководствовались другие разработчики, которые так или иначе будут продолжать писать свои шаблонизаторы. Поверьте, это уже будет не мало.
Безусловно не будет просто. Но сами посудите, данные для всех одинаковы. Основные конструкции присутствуют в каждом языке программирования. Конечно совсем все языки программирования не получится, но это и не самоцель.
Это у вас шутки такие?
Как, по вашему, пройтись по элементам массива без цикла?
Поверьте, срезы массивов тоже бывают нужны. Количество элементов в массиве данных не всегда удается изменить здесь и сейчас. Источник данных один, в шаблоне используется в двух местах, но где-то первая половина, где-то вторая. Как-то вы агрессивно реагируете.
Элемент <xsl:apply-templates> сначала выбирает набор узлов с помощью выражения, заданного атрибутом select.Если этот атрибут не задан, выбираются все дочерние элементы текущего узла.Для каждого из выбранных узлов атрибут <xsl:apply-templates> указывает обработчику XSLT, что нужно найти соответствующий шаблон <xsl:template> для применения.Применимость шаблонов проверяется сравнением узла с выражением XPath, заданным в атрибуте match данного шаблона.Если соответствие найдено для нескольких шаблонов, выбирается шаблон с наивысшим приоритетом.Если несколько шаблонов имеют одинаковый приоритет, выбирается тот, который расположен в таблице стилей последним.
Если я правильно понимаю, то такой подход диктуется особенностью самой связки xml+xslt.
В случае когда шаблон будет компилироваться в нативный код языка программирования, использование конструкций if/else не имеет побочных эффектов. А если целью стоит читабельность основного шаблона, то можно применять инклуды/блоки, которые будут по выбранному набору данных вставлять уже более подробный кусок html.
А если вам нужно в зависимости от одних данных генерировать часть шаблона, используя уже другие данные? То есть проверки if / else уже не избежать.
Дак вот что-что, а заниматься этим очень узким кругом людей (раз-два) точно не хочется.
Во-первых это не сильно в конечном итоге будет отличаться от того что есть.
Во-вторых, разные люди — разные мнения, что важно — много здравых идей
В-третьих, нудно постараться реализовать примеры на разных языках, а квалификация такое не позволяет. Без примеров нельзя(как и зацикливаться на них) — нужно анализировать то, что будет получаться не только в теории.
Вы сказали что враппер (интерфейс) — пустой перевод байт. Нет. Это одна из составляющих стабильности и успеха.
Но для _старта_ или _быстрой_сборки_ можно использовать прозрачное проксирование методов внешнего ресурса через интерфейс (но он должен быть с самомго начала). Опционально должно быть «исключение» интерфейса, а не его включения.
Но это всё теория. Если мы задумываемся о использовании этих концепций, значит у нас уже можно разбить систему на составляющие, которые со старта дожны быть изолированными.
А что нужно? Как хороший пример — реализация в java. Я не владею этим языком, но изучение темы в сети дало вот что. Между приложением MyApp и классами DB и Log должен быть «интерфейс». Пусть у нас это будут iDB и iLog соответсвенно. Пусть в нашем приложении от Log необходим только метод error. Тогда интерфейс iLog должен иметь алиас error который вызывает Log->error или Log2->i_am_error в зависимости от того, какой внешний класс нам нужен. Я опустил, что интерфес так же должен управлять передачей аргументов по установленным правилам.
И вот теперь мое приложение MyApp будет использовать систему логирования или записи в БД независимо от реализации классов. Приложение будет использовать интерфейс, который гарантирует наличие необходимых методов.
У нас в perl например Bread::Board (http://search.cpan.org/dist/Bread-Board/) так же передаёт непосредственно хэндлеры внешних классов DB и Log в приложение. Это вроде как не совсем то, что нужно.
Может быть потому, что нет подобных реализаций и не используют?
всё равно непонятно
Ремарку про отсутствие самих докладов почитал. Просто хотелось хоть немного видеть доклад на видео.
Не понятно, почему хотя бы изредка не показывали слайды доклада.
В логах так и увидите
"/userprfile/?id=123"
"/lastcomment/?userid=123"
«mysite.ru/main/»
И, если вы установили в глобальный обработчик функцию проверки аутентификации, она выполнится три раза. Вы на один запрос пользователя будете его авторизовывать три раза.
Нужно очень внимательно смотреть на то, что вы подключаете как SSI. Такая вот горе оптимизация, ведет к тому, что вы усложняете работу вашего движка/скрипта…
В первом случае у нас обычный вызов инклуда, во втором имя инклуда передается в переменной, где # сигл, указывающий что за ним идет переменная.
Так сложно такое представить? Не подходит для составления основного шаблона из разных кусочков?
Ну скажем что это еще не самое страшное в жизни. Но при этом все же, вот как в примере, есть массив элементов, и нужен только конкретный элемент. Озадачиться обработкой данной ситуации в контроллере, или дать таки возможность обращаться к элементам массива по индексу?
В пункте 2.2 я написал, что запись почти все ЯП так или иначе поддерживают большиство операторов, отличия лишь в написании. Значит в шаблоне нужно будет использовать какой-то оговоренный синтаксис операторов, который парсером будет транслироваться в оператор заданного яп.
4. Инклуды
В первом случае мы вставляем инклуд nameinclude, в качестве текущего объекта, будет объект, в контексте которого идет вызов инклуда. Во втором случае текущим объектом в инклуде tpl_comments будет выступать объект source.comment_data
Второй абзац не понял, но думается вы хотите что-то сказать, связанное с xslt. От того, что выборка определенных элементов производится по какому то признаку, и проход по ним для вас прозрачен, это не отменяет итерации этих элементов.
5. Статья на хабре про наследование в Django: habrahabr.ru/blogs/django/23132/
Описать тривиальные конструкции нужно для того, чтобы обозначить отправные точки для дальнейшего обсуждения, и поинтересноваться, может стоит добавить что-то еще?
Наверное стоило их совсем убрать из примеров…
Как, по вашему, пройтись по элементам массива без цикла?
Поверьте, срезы массивов тоже бывают нужны. Количество элементов в массиве данных не всегда удается изменить здесь и сейчас. Источник данных один, в шаблоне используется в двух местах, но где-то первая половина, где-то вторая. Как-то вы агрессивно реагируете.
Если я правильно понимаю, то такой подход диктуется особенностью самой связки xml+xslt.
В случае когда шаблон будет компилироваться в нативный код языка программирования, использование конструкций if/else не имеет побочных эффектов. А если целью стоит читабельность основного шаблона, то можно применять инклуды/блоки, которые будут по выбранному набору данных вставлять уже более подробный кусок html.
А если вам нужно в зависимости от одних данных генерировать часть шаблона, используя уже другие данные? То есть проверки if / else уже не избежать.
Или я не до конца уяснил идею?
Во-первых это не сильно в конечном итоге будет отличаться от того что есть.
Во-вторых, разные люди — разные мнения, что важно — много здравых идей
В-третьих, нудно постараться реализовать примеры на разных языках, а квалификация такое не позволяет. Без примеров нельзя(как и зацикливаться на них) — нужно анализировать то, что будет получаться не только в теории.