Comments 19
Я думаю, что «мэтры 1С» по какой-то объективной причине поддались XML-хайпу и не читали других мэтров, международных, типа Фаулера. Потому что у него английским по белому сказано, что XSLT стОит применять на 2ом шаге Two-Step View, создавая представление из готовой View Model (в том же самом шаблонизаторе); View Model же сама по себе готовится «классическим» способом, и никаких XSLT там быть не «советовано».
З.Ы. За полетом вашей мысли следить было сложно, да :)
З.Ы. За полетом вашей мысли следить было сложно, да :)
как-то сумбурно… и сильно оторванные метафоры…
Ну прям на пальцах всё! =) Отлично.
чувак только вчера зарегистрировался, а уже такие топики пишет. Респект!
UFO just landed and posted this here
Немного сумбурно…
а так… я думал для всех очевидная вещь, используй — не используй XML-XSLT, но если во вью-ху оттоеш туеву- кучу данных то оно логично что будет жрать память и тормозить)
а так… я думал для всех очевидная вещь, используй — не используй XML-XSLT, но если во вью-ху оттоеш туеву- кучу данных то оно логично что будет жрать память и тормозить)
А я тут, кстати, подумал, а чем HTML или XHTML, по сути не данные? А чем CSS не стили? Получается та же свистопляска. И в принципе, используя XML-XSLT, мы окунаемся в море ограничений и частностей, которые ломают всю идеальную картину и мы приходим всё к тому же сумбуру, от которого пытались отрешиться.
если бы css было бы достаточно, никто бы и не рыпался делать xsl ;-)
Тем что CSS не предназначен для преобразования ожного документа в другой. Для этого предназначен XSLT, при помощи которого один документ преобразовывается в другой. Т.е. один и тот же XML при помощи другой вид документа. Не только xHTML но и в pdf, rtf и т.д.
Если применение CSS к HTML только на финале, применять XSLT к тому же xHTML можно несколько раз по цепочке. Например сначала получается базовый xHTML без дизайнерских прибабахов. Затем при помощи других преобразований из него получается версия для печати, версия для PDA, полная версия, версия для идиотов и т.д. Т.е. свобода действий не сравнимая даже в первом приближении с www.csszengarden.com
Если применение CSS к HTML только на финале, применять XSLT к тому же xHTML можно несколько раз по цепочке. Например сначала получается базовый xHTML без дизайнерских прибабахов. Затем при помощи других преобразований из него получается версия для печати, версия для PDA, полная версия, версия для идиотов и т.д. Т.е. свобода действий не сравнимая даже в первом приближении с www.csszengarden.com
По сути, css к этому стремится, но не структурно, а визуально, ту же принт-версию или pda версию можно получить, манипулируя css стилями, а что касается той же pda версии — то здесь необходимы уже серверные инструменты, исходя, даже, из необходимости оптимизации. И нужна ли эта свобода действий, если есть устоявшиеся рамки и правила в построении интерфейсов?
>По сути, css к этому стремится, но не структурно, а визуально
Мне кажется вы сами себе ответили в чем разница.
>что касается той же pda версии — то здесь необходимы уже серверные инструменты
Вроде никто особо не предлагает вынести XSLT на клиента. Оно конечно очень и очень привлекательно, но страшно геморройно. Хотя если бы броузеры умели по полной программе работать с XSLT это существенно облегчало бы те же дублирующие версии.
Можно было бы передавать клиенту самый минимум (ту же PDA версию) и наращивать его ссылками на XML/XSLT в которых передавать то чем отличается PDA от полной версии. Примерное то что сейчас пытаются сделать на Ajax.
Посмотрите например как прилепляется правая колонка на этом сайте: www.erum.ru
>И нужна ли эта свобода действий,
>если есть устоявшиеся рамки и правила в построении интерфейсов?
Каких интерфейсов? Программных или юзерских?
Юзерские к этому делу отношения никакого не имеют. А с программными XSLT как минимум вводит разработчиков в русло единой и W3C стандартной среды разработки. Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
Мне кажется вы сами себе ответили в чем разница.
>что касается той же pda версии — то здесь необходимы уже серверные инструменты
Вроде никто особо не предлагает вынести XSLT на клиента. Оно конечно очень и очень привлекательно, но страшно геморройно. Хотя если бы броузеры умели по полной программе работать с XSLT это существенно облегчало бы те же дублирующие версии.
Можно было бы передавать клиенту самый минимум (ту же PDA версию) и наращивать его ссылками на XML/XSLT в которых передавать то чем отличается PDA от полной версии. Примерное то что сейчас пытаются сделать на Ajax.
Посмотрите например как прилепляется правая колонка на этом сайте: www.erum.ru
>И нужна ли эта свобода действий,
>если есть устоявшиеся рамки и правила в построении интерфейсов?
Каких интерфейсов? Программных или юзерских?
Юзерские к этому делу отношения никакого не имеют. А с программными XSLT как минимум вводит разработчиков в русло единой и W3C стандартной среды разработки. Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
> Вроде никто особо не предлагает вынести XSLT на клиента.
Тут дело в том, что отличаться структура будет сильно, вплоть до выборки из БД, так что в любом случае структуры xml будут разными.
>Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
XML, тем более с XSLT, достаточно сложен для понимания, а долбаные CMS стараются быть доступными для секретуток. Поэтому соревнуются в простоте.
>Каких интерфейсов? Программных или юзерских?
Я имел ввиду именно пользовательских, а конкретнее способы отображения информации для разных нужд или устройств.
Тут дело в том, что отличаться структура будет сильно, вплоть до выборки из БД, так что в любом случае структуры xml будут разными.
>Сейчас у каждой долбанной CMS свой долбанный шаблонизатор. Свобода на грани анархии.
XML, тем более с XSLT, достаточно сложен для понимания, а долбаные CMS стараются быть доступными для секретуток. Поэтому соревнуются в простоте.
>Каких интерфейсов? Программных или юзерских?
Я имел ввиду именно пользовательских, а конкретнее способы отображения информации для разных нужд или устройств.
>Тут дело в том, что отличаться структура будет сильно, вплоть до выборки из БД, так что в любом случае структуры xml будут разными.
Ядро любой контент-страницы (новость-статья-описание товара) всегда одно и то-же. Отличие версий как правило только в обвесках и дизайне. Все это можно наворачивать вторым/третьим преобразованием
>Поэтому соревнуются в простоте.
Увы и ах, правда ваша. Хотя UMI и HostCMS в топ-рейтингов все же пролезают. B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
>Я имел ввиду именно пользовательских
Ну тут как раз без разницы откуда взялась картинка на экране.
Ядро любой контент-страницы (новость-статья-описание товара) всегда одно и то-же. Отличие версий как правило только в обвесках и дизайне. Все это можно наворачивать вторым/третьим преобразованием
>Поэтому соревнуются в простоте.
Увы и ах, правда ваша. Хотя UMI и HostCMS в топ-рейтингов все же пролезают. B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
>Я имел ввиду именно пользовательских
Ну тут как раз без разницы откуда взялась картинка на экране.
Тут получается такая же ситуация, как и недавно мы спорили с ребятами о приемлимости совместного использования UML и подхода Getting Real и agile практив в целом. Правда, там я был за uml, а они против :)
>B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
Да мне кажется, всё равно в этом смысла немного. Технологию нужно использовать там, где она действительно необходима. А XSLT на данный моммент слишком тяжела, чтобы использовать её. Лучшим вариантом было бы формирование отображения на стороне пользователя, но неизвестно, когда браузеры в едином порыве это реализуют.
>B и если Котырев здесь habrahabr.ru/blogs/about_cms/22018/ не сочиняет, положение через несколько лет должно изменться.
Да мне кажется, всё равно в этом смысла немного. Технологию нужно использовать там, где она действительно необходима. А XSLT на данный моммент слишком тяжела, чтобы использовать её. Лучшим вариантом было бы формирование отображения на стороне пользователя, но неизвестно, когда браузеры в едином порыве это реализуют.
>А XSLT на данный моммент слишком тяжела, чтобы использовать её.
На вкус и цвет. По мне так XSLT все намного упрощает и облегчает. А то что верстальщикам тяжело его учить — так для 99% говносайтов что идут на потоке в вебстудиях особо заковыристого XSLT не нужно. Можно обойтись тупым кодом с одним единственным xsl:teplate
На вкус и цвет. По мне так XSLT все намного упрощает и облегчает. А то что верстальщикам тяжело его учить — так для 99% говносайтов что идут на потоке в вебстудиях особо заковыристого XSLT не нужно. Можно обойтись тупым кодом с одним единственным xsl:teplate
Сорри конечно, но статья рыжикова достаточно древняя и пережевана много раз. Самое большое обсуждение было на хабре habrahabr.ru/blogs/about_cms/22018/ — после ответа Котрырева (UMI CMS) Рыжкову
UFO just landed and posted this here
Sign up to leave a comment.
Суровые челябинские 1С-разработчики и как же юзать XSLT