Comments 21
Я бы ещё упомянул XUL - XML User Interface Language, разработанный Мозиллой. На нем построен интерфейс Фаерфокса и всех его расширений. Но кроме этого его также можно использовать в т.н. режиме "remote XUL" - практически так же, как HTML, но вместо input'ов, select'ов и div'ов он предлагает button'ы, menulist'ы и tree. В качестве языка программирования для обработки событий интерфейса используется, конечно же, старый добрый javascript.
Особенность XUL'а в том, что его интерфейс выглядит в соответствии с ОС пользователя, используя родые стили контролов для этой ОС. Минус - несмотря на внушительный возраст, XUL всё же плохо приспособлен именно для remote-режима с ограниченными привилегиями (например, никакого чтения и записи локальных файлов пользователей ;)) и имеет несколько досадных багов, которые Моззиловцы не могут исправить буквально годами...
Пример приложения на XUL пользователи Firefox могут посмотреть тут:
http://www.faser.net/mab/chrome/content/mab.xul
Особенность XUL'а в том, что его интерфейс выглядит в соответствии с ОС пользователя, используя родые стили контролов для этой ОС. Минус - несмотря на внушительный возраст, XUL всё же плохо приспособлен именно для remote-режима с ограниченными привилегиями (например, никакого чтения и записи локальных файлов пользователей ;)) и имеет несколько досадных багов, которые Моззиловцы не могут исправить буквально годами...
Пример приложения на XUL пользователи Firefox могут посмотреть тут:
http://www.faser.net/mab/chrome/content/mab.xul
любопытная штуковина. согласен, стоит упоминания.
вот только смысл ее использования, с такими недостатками и поддержкой одного популярного браузера?
вот только смысл ее использования, с такими недостатками и поддержкой одного популярного браузера?
Мне довелось использовать его в одном интранетовском проекте, где среда контролируется "сверху" и всем пользователям была "принудительно" установлена Лисичка :)
А в обычных проектах его имеет смысл использовать исключительно в админках и исключительно энтузиастами. Раньше, когда небыло ExtJS, XUL выглядил намного интереснее, а сейчас... остался последний аргумент - производительность. На XUL'е можно без особых проблем создать такой интерфейс, аналог которого на Эксте убил бы браузер пользователя моментально.
А в обычных проектах его имеет смысл использовать исключительно в админках и исключительно энтузиастами. Раньше, когда небыло ExtJS, XUL выглядил намного интереснее, а сейчас... остался последний аргумент - производительность. На XUL'е можно без особых проблем создать такой интерфейс, аналог которого на Эксте убил бы браузер пользователя моментально.
эмм.. а покажите пример, плиз. а то все что я видел на XUL - убогое и серое :(
FireFox, Komodo. Этого не достаточно?
Основные примеры уже назвали - это Firefox, Thunderbird, Komodo... но это всё - обычный (application XUL), а примеров именно remote XUL под веб - не так уж и много.
Самый известный - это Mozilla Amazon Browser, ссылку на него я уже привел выше.
Кроме того, можно взглянуть на пример использования практически всех XUL'овских контролов вот тут:
http://www.hevanet.com/acorbin/xul/top.xul
Само собой, контролы выглядят по-разному в зависимости от ОС и настроек "темы" пользователя.
По поводу "серости" - XUL берет её из настроек ОС точно так же, как это делают остальные десктопные приложения. А "убогость" - тут с вами не соглашусь. Это не убогость, это аскетичность. Любой контрол XUL'а можно разукрасить как угодно при помощи обыкновенных CSS. Только тогда основной смысл XUL'а теряется - не будет никакой адаптации под настройки и ОС пользователя. Контролы на WinXP будут выглядеть так же, как и на Маке и т.д.
Самый известный - это Mozilla Amazon Browser, ссылку на него я уже привел выше.
Кроме того, можно взглянуть на пример использования практически всех XUL'овских контролов вот тут:
http://www.hevanet.com/acorbin/xul/top.xul
Само собой, контролы выглядят по-разному в зависимости от ОС и настроек "темы" пользователя.
По поводу "серости" - XUL берет её из настроек ОС точно так же, как это делают остальные десктопные приложения. А "убогость" - тут с вами не соглашусь. Это не убогость, это аскетичность. Любой контрол XUL'а можно разукрасить как угодно при помощи обыкновенных CSS. Только тогда основной смысл XUL'а теряется - не будет никакой адаптации под настройки и ОС пользователя. Контролы на WinXP будут выглядеть так же, как и на Маке и т.д.
Обзор, конечно, на полноту не претендовал, этим фреймворкам сейчас имя легион. XUL хорошая щтука, но, как, верно тут заметили, с кросс-браузерностью у него завал.
Поправочка: XUL - это язык, а не фреймворк.
С полнотой статьи всё отлично, XUL нельзя напрямую сравнивать с этими фреймворками.
Просто вспомнился он мне, подумал что другим хабрадевелоперам может быть интересно.
А кросс-браузерность - это не всегда аргумент, всё зависит от целей. Тот же ExtJS, а точнее его десктоп, вряд ли где-то кроме админок можно широко использовать. Конечно, могут быть специфические приложения, где его стоит использовать в публичной части, но такие приложения - скорее исключения, ИМХО.
С полнотой статьи всё отлично, XUL нельзя напрямую сравнивать с этими фреймворками.
Просто вспомнился он мне, подумал что другим хабрадевелоперам может быть интересно.
А кросс-браузерность - это не всегда аргумент, всё зависит от целей. Тот же ExtJS, а точнее его десктоп, вряд ли где-то кроме админок можно широко использовать. Конечно, могут быть специфические приложения, где его стоит использовать в публичной части, но такие приложения - скорее исключения, ИМХО.
отличный исторический обзор)
вот только «новое время» немного хромает) ajax появился много позже замечательного flash mx, а vbscript я, если честно, и вовсе не встречал))
вот только «новое время» немного хромает) ajax появился много позже замечательного flash mx, а vbscript я, если честно, и вовсе не встречал))
Не совсем в теме, но очень интересно, как с безопасностью генерируемого этими фреймворками кода?
я полагаю, лучше чем у кода bestpersons.ru)
Хороший вопрос, про это можно написать отдельную статью. Ajax, конечно, сильно уязвим. Не говоря уже о том, что большинство ajax-based фреймворков в той или иной форме используют eval, что даёт простор для воспалённой фантазии. Но подобные технологии обычно задействуются при разработке приложений, а не онлайн-сервисов, что сокращает потенциальный круг атак.
А чем плох eval? Если он интерпретирует на клиенте данные переданные родным сервером?
Тем, что в эти данные можно подмешать вредоносный код, который исполнится в броузере с соответствующим правами. Если в традиционных аппликациях понятно, что надо перед публикацией страницы резать весь js напрочь, то тут валидацию на сервере делать куда сложнее.
Я наверное просто не сталкивался с такими случаями... Я как раз таки не понимаю как можно что-то подмешать в данные, которые генерируются по известными скриптам на сервере или пишуться своим программером?
А javascript можно же вырезать и при получении данных от пользователя?
А javascript можно же вырезать и при получении данных от пользователя?
Подмешать можно разными способами. Можно взломать базу данных сервера и поместить туда payload, можно взломать сам сервер и подменить скрипт, можно устроить dns атаку и подменить вызываемый адрес сайта. Но самый распространённый случай, конечно, это когда пользовательский ввод возвращается с сервера без валидации. Пример гостевые книги и форумы. Данные генерируются известным скриптом, но сами данные приходят от пользователя.
Jscript надо вырезать на сервере, но если мы знаем, что легальная страница может его содержать (а многие ajax-фреймфорки допускают jscript в коде страниц, по сути, эти страницы создают объекты, которые потом динамически добавляются в страницу), то вырезать вредоносный код и не затронуть код программы становится не так-то просто.
Jscript надо вырезать на сервере, но если мы знаем, что легальная страница может его содержать (а многие ajax-фреймфорки допускают jscript в коде страниц, по сути, эти страницы создают объекты, которые потом динамически добавляются в страницу), то вырезать вредоносный код и не затронуть код программы становится не так-то просто.
Согласен, действительно, автоматически определить что из кода легальное, а что - нет очень сложно. Но с другой стороны, если взломали сервер (или базу данных в частности), то можно в страницы вставлять полноценные куски кода независимо от наличия eval'а в оригинальных скриптах.
Может быть как дополнительную ступеньку защиты использовать проверку Gears'ами всех данных на стороне клиента?
Может быть как дополнительную ступеньку защиты использовать проверку Gears'ами всех данных на стороне клиента?
Большое спасибо за обзор. Пример с рабочим столом вообще поразил очень сильно, сразу начинаю чувствовать свою осталость в области веб-конструирования. :-)
Давно уже задумывался о выборе платформы для одного своего проекта, который как раз будет очень активно взаимодействовать с пользователем… Похоже, ExtJs станет моим выбором. Ещё раз спасибо!
Давно уже задумывался о выборе платформы для одного своего проекта, который как раз будет очень активно взаимодействовать с пользователем… Похоже, ExtJs станет моим выбором. Ещё раз спасибо!
Sign up to leave a comment.
О некоторых современных технологиях разработки веб-интерфейсов