Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 91
«Дело за тобой, уважаемый читатель!»
что от на требуется чтобы вы продолжали в том же духе освещать «сравнение по пунктикам JavaScript и Adobe Flash, плюсы и минусы «больших» веб-фреймворков для создания RIA, лавирование между SOAP и REST, задачи и проблемы процесса создания системы скриптов для автоматического тестирования и разворачивания клиентского js-кода, централизованное использование микроформатов…»?
:)
спасибо за статью, очень хорошо подано
что от на требуется чтобы вы продолжали в том же духе освещать «сравнение по пунктикам JavaScript и Adobe Flash, плюсы и минусы «больших» веб-фреймворков для создания RIA, лавирование между SOAP и REST, задачи и проблемы процесса создания системы скриптов для автоматического тестирования и разворачивания клиентского js-кода, централизованное использование микроформатов…»?
:)
спасибо за статью, очень хорошо подано
Да, мега статья.
Вроде выложены простые истины, которыми никого не удивишь, но читать невероятно интересно.
Подача, оформление и язык — на высоте!
Юраво
Вроде выложены простые истины, которыми никого не удивишь, но читать невероятно интересно.
Подача, оформление и язык — на высоте!
Юраво
Отличная статья. Сейчас как раз кручу Adobe Flex + ROR
Спасибо. Сейчас как раз купил справочник по JS и начинаю разбираться. Ваша статья помогла.
Отличный пример статьи, которую приятно почитать даже человеку, не искушенному в AJAX и Java Script. Спасибо.
Очень интересно… приятно было прочитать…
С нетерпением жду продолжения
С нетерпением жду продолжения
Великолепная статья, в стиле хабра. Спасибо!
еще иногда могут быть полезными GET и POST
Да, если использовать технологию AJAX вместе с методами, то получаются очень крутые вещи. Постоянно использую методы передачи данных и все рекомендую.
PS Хабравтор, большое спасибо за хабростатью! Оказывается в JavaScript есть ООП, хотя программисты мне говорили, что его в нем нет — больше не буду им верить.
PS Хабравтор, большое спасибо за хабростатью! Оказывается в JavaScript есть ООП, хотя программисты мне говорили, что его в нем нет — больше не буду им верить.
всётаки не удержусь:
Спасибо. Это отличный способ управления данными, который Вы опубликовали первым.
Не будучи против вашей идею хочу сказать, что модель MVC более применима к серверным языкам, нежели к JavaScript. Все проверки, защиту от инъекций, обработка, вывод лучше проводить на сервере, нежели на машине клиента. Но статья хороша, держи краба =8)
Не будучи против вашей идею хочу сказать, что модель MVC более применима к серверным языкам, нежели к JavaScript. Все проверки, защиту от инъекций, обработка, вывод лучше проводить на сервере, нежели на машине клиента. Но статья хороша, держи краба =8)
Прошу прощения, если ввел вас в заблуждение упоминанием MVC, я хотел на примере популярного паттерна показать абстрактную структуру для описываемого приложения. Разумеется, данным от клиента доверять не стоит вообще, однако, для удобства пользователя, проверки и уведомления об ошибках валидации на стороне клиента все же необходимы. Если вы не хотите дублировать функционал, можете воспользоваться предложенным в этой статье способом обработки ошибок ;)
Мне кажется Ваш вариант очень подходит допустим для пост-загрузки текста новостей(т.е. сначало грузим страницу, как только DOM готов, загружаем последние 5 новостей при помощи ajax) и листалки новостей, но никак не для авторизации пользователей.
К авторизации относиться нужно очень серьезно и большинство программистов делают дыры в безопасности (так показывает статистика) именно на этапе авторизации\регистрации
К авторизации относиться нужно очень серьезно и большинство программистов делают дыры в безопасности (так показывает статистика) именно на этапе авторизации\регистрации
Спасибо. Грамотный подход и отличная статья.
Я бы, правда, не стал ограничивать протокол общения клиента и сервера одним только JSON'ом. В больших приложениях зачастую бывает полезно докачивать CSS и JS (собственно, части клиентский код) не сразу, а по мере необходимости. Тут одним JSON'ом не обойдёшься.
Я бы, правда, не стал ограничивать протокол общения клиента и сервера одним только JSON'ом. В больших приложениях зачастую бывает полезно докачивать CSS и JS (собственно, части клиентский код) не сразу, а по мере необходимости. Тут одним JSON'ом не обойдёшься.
части клиентского кода, разумеется
Мне кажется, что отдавать даже несжатый css и js код клиенту за один раз проще, чем добавлять к клиенту и серверу функциональность по их подгрузке. К тому же, это нарушит чистоту архитектуры, одним из условий которой является зависимость клиента и сервера только от протокола обмена, а не друг от друга. Ведь по сути, сервер может работать без изменений в коде с любым клиентом, не только базирующимся на html+css+js, к примеру, это может быть flash.
Мне кажется, что отдавать даже несжатый css и js код клиенту за один раз проще, чем добавлять к клиенту и серверу функциональность по их подгрузке.
Зависит от сложности приложения, согласитесь.
К тому же, это нарушит чистоту архитектуры
Не то, чтобы нарушит. Дополнит, я бы сказал.
сервер может работать без изменений в коде с любым клиентом
Мы тут о разных серверах, похоже, говорим. Вы имеете в виду сервер приложения, я же в предыдущем комментарии имел в виду сервер, с которого пользователь получает клиента. Это не обязательно одно и то же.
Но, в общем, динамическая подгрузка клиента, наверное, действителньо выходит за рамки предложенной вами архитектуры и статьи, соответственно.
Кстати, по моему говорить, что JS — ООП, как-то неправильно. Это всё-таки прототип-ориентированный язык (и это было бы интересно в статье) и как такого понятие класса у него нет (function Class() { this.x = 3 } это скорее «конструктор»).
Спасибо за уточнение, я постарался привести краткое описание в первую очередь для людей, которые не знакомы с js или малознакомы с ним. К сожалению, узкие рамки фомата статьи не позволяют концентрировать внимание на таких тонкостях.
Просто меня смущает, что из-за доминирования C\C++, Java и C# большинство программистов знают только ООП парадигму и то, совсем новую и упрощённую ООП. В Smalltalk (эталонная реализация ООП) всё было совсем по другому :). Например, эту ветвь ООП сохраняют сейчас Ruby и Objective-C. А ведь есть ещё функциональные, прототип-ориентированные языки,, где нужны совсем другой подход и немного другое мышление, но их практически не преподают в должном объёме.
а если произвести перехват и подмену пакетов? или допустим модифицировать код движка?
Ситуация один в один схожа с любым другим сайтом или приложением, работающим через сеть — перехватить и модифицировать можно любые пакеты, вопрос в том, что сделали авторы данного приложения, что бы обезопасить пользователя. Передают ли критичные данные через защищенные соединения, например.
Если Вася Помидоров попытается получить права СуперАдмина, а владеет только правами СреднегоЮзера, то сколько бы он не слал модифицированных пакетов на сервер, тот равнодушно позволит менять ему данные только от имени СреднегоЮзера, да еще и забанить может за такое :)
Если Вася Помидоров попытается получить права СуперАдмина, а владеет только правами СреднегоЮзера, то сколько бы он не слал модифицированных пакетов на сервер, тот равнодушно позволит менять ему данные только от имени СреднегоЮзера, да еще и забанить может за такое :)
Спасибо, отличная статья! На работе как раз используем такую модель, с помощью отличного фреймоворка Qooxdoo. Все никак не допишу про него статью…
Спасибо за ссылку, обязательно познакомлюсь с Qooxdoo. :)
очень интересный фреймворк!
а как у него с производительностью в сравнении с ext js, подскажите?
а как у него с производительностью в сравнении с ext js, подскажите?
Производительность высокая, были проблемы с IE6. Сравнить с ext js не могу, но когда мы выбирали, ext js выигрывал по интерфейсу, но проигрывал с точки зрения функциональности и не предоставлял полную обьектную модель. Qooxdoo очень большой фреймворк, не только интерфейс но и работа со строками, ajax, xml и тп. Правда сейчас наш проект подходит к концу, и получился довольно внушительных размеров js файл что нельзя считать плюсом.
Спасибо, правда написано отличным языком. Читается легко.
У меня вопрос назрел: в вашем примере после авторизации разблокируется какой-то функционал у клиента. Не является ли это уязвимостью? Не лучше ли после авторизации подгружать с сервера данные, разрешенные для авторизованного пользователя?
У меня вопрос назрел: в вашем примере после авторизации разблокируется какой-то функционал у клиента. Не является ли это уязвимостью? Не лучше ли после авторизации подгружать с сервера данные, разрешенные для авторизованного пользователя?
Клиент в руках врага :) Вам по сути, никто не помешает модифицировать код Хабра у себя в браузере, к примеру добавить своему другу 1 000 000 кармы. Однако, на сервере ваш запрос на миллион кармы будет отклонен, разумеется. Тут идентичная ситуация — все ваши хаки будут распространены только на клиент, а сервер их просто отбросит.
Блокировка функций — следствие идеологии паттерна, которая гласит, что клиент должен сразу иметь весь функциональный код при загрузке.
Блокировка функций — следствие идеологии паттерна, которая гласит, что клиент должен сразу иметь весь функциональный код при загрузке.
Да, наверное надо делать так, чтобы клиентская сторона не содержала никаких данных, только функционал. Тогда и подсмотреть будет нечего.
Вы не против еще одного вопроса? Вы предлагаете совершенно иной подход к приложению, хочу понять, возможно ли мне реализовать это.
В моих приложениях, в ответ на действия пользователя, серверная сторона подготавливает какой-то HTML код и отправляет клиенту с инструкциями куда его поместить. Так происходит отображение состояния приложения. Вы предлагаете передавать только данные в JSON виде. Представление должно формироваться на клиентской стороне, да? Как на основе этих данных подготовить HTML и отобразить страницу?
Вы не против еще одного вопроса? Вы предлагаете совершенно иной подход к приложению, хочу понять, возможно ли мне реализовать это.
В моих приложениях, в ответ на действия пользователя, серверная сторона подготавливает какой-то HTML код и отправляет клиенту с инструкциями куда его поместить. Так происходит отображение состояния приложения. Вы предлагаете передавать только данные в JSON виде. Представление должно формироваться на клиентской стороне, да? Как на основе этих данных подготовить HTML и отобразить страницу?
Как я понимаю, вы не пользуетесь фреймворками навроде extjs? Для своего приложения мы в самом начале заготовили обычные сверстаные макеты всех типовых элементов: окошек, менюшек и т.д, разметили структуру главной страницы и «захардкодили» логику построения всего этого добра в js. К примеру, главное меню отрисовывет класс MainMenu, а вот уже доступные действия подружаются в виде json-списков с сервера.Т.е, по сути, весь html помещен в обертки из js — поэтому клиент вообще не зависит от сервера. Если вы не планируете переход на другие виды клиентов, к примеру флеш или нативные десктопные клиенты, вам может и не понадобится такое отделение.
в избранное!
но на стороне клиента трудится не только JS но ещё Flash,
но на стороне клиента трудится не только JS но ещё Flash,
Честно говоря не понравилось. Может быть будет полезно новичкам — да, но я думаю что человек который тольк оподошел к веб-разработке(а точнее клиент-серверной разработке в целом) начинать работу с попыток делать RIA — не правильно. Шанс что выйдет что-то стоящее не велик, а знаний от этого не прибавится.
А для не новичка статья читается очень медленно и сложно.
А для не новичка статья читается очень медленно и сложно.
Новичок в RIA не обязательно новенький в программировании вообще. К примеру, если он хочет получить легкий в разработке кроссплатформенный тонкий клиент для уже существующей системы, то RIA будет отличным решением, по моему мнению. Сожалею, что мой стиль заставил потратить ваше время.
Я не сказал что статья бесполезна. =) Я сказал что ее ценность спорна.
Для не новичка в программировании(тем более в веб программировании), я думаю не нужны были бы описания элементарных возможностей JavaScript, или клиент-серверной технологии.
Если была поставлена цель описать конецпцию RIA применительно к веб-разработке то она выполнена но только наполовину. Первая половина статьи не про RIA вообще. То что используется концепция передачи всего клиентского кода во время первой сессии, описано мимолетом например, а для нвоичка это будет тем что отличает RIA от других технологий. =)
Для не новичка в программировании(тем более в веб программировании), я думаю не нужны были бы описания элементарных возможностей JavaScript, или клиент-серверной технологии.
Если была поставлена цель описать конецпцию RIA применительно к веб-разработке то она выполнена но только наполовину. Первая половина статьи не про RIA вообще. То что используется концепция передачи всего клиентского кода во время первой сессии, описано мимолетом например, а для нвоичка это будет тем что отличает RIA от других технологий. =)
соглашусь с nileriver пожалуй, ибо так я и не смог понять, для чего/кого написана эта статья. Тем, кто хорошо разбирается в вопросе, ничего нового сказано не было… хотя, возможно, новичкам будет интересно.
пока читал — постоянно возникало недоумение по поводу очень многих утверждений. По настоящему Rich интерфейс никакой ява скрипт сделать не поможет по той простой причине, что он оперирует крайне ограниченными средствами html/css (с натяжкой ещё svg и некоторыми другими).
Технически очень сложно сделать более или менее продвинутый и удобный интерфейс, который бы ещё и был достаточно быстрым, чтобы соперничать с десктопными продуктами (собственно, кроме gmail вообще ничего на ум не приходит, но даже он на самом деле далеко не так быстр и отзывчив, как десктопные аналоги).
AJAX — это по большому счету костыли. Пусть меня закидают помидорами, но только ajax ни разу не является удобной технологией для обмена данными с сервером. Просто выбора нет, вот и приходится изголяться.
Чтобы действительно качественные изменения были — нужна очень серьезная работа в области новых стандартов (html5/css3 или ещё каких-то), чтобы браузеры научились показывать нативно хотя-бы половину тех виджетов, которые доступны программистам на всяких gtk/qt/winforms/и т.д.
нужны _нормальные_ средства для обмена данными с сервером. И всё это будет… когда-нибудь :)
а до тех пор — так и будут делаться новые костыли
пока читал — постоянно возникало недоумение по поводу очень многих утверждений. По настоящему Rich интерфейс никакой ява скрипт сделать не поможет по той простой причине, что он оперирует крайне ограниченными средствами html/css (с натяжкой ещё svg и некоторыми другими).
Технически очень сложно сделать более или менее продвинутый и удобный интерфейс, который бы ещё и был достаточно быстрым, чтобы соперничать с десктопными продуктами (собственно, кроме gmail вообще ничего на ум не приходит, но даже он на самом деле далеко не так быстр и отзывчив, как десктопные аналоги).
AJAX — это по большому счету костыли. Пусть меня закидают помидорами, но только ajax ни разу не является удобной технологией для обмена данными с сервером. Просто выбора нет, вот и приходится изголяться.
Чтобы действительно качественные изменения были — нужна очень серьезная работа в области новых стандартов (html5/css3 или ещё каких-то), чтобы браузеры научились показывать нативно хотя-бы половину тех виджетов, которые доступны программистам на всяких gtk/qt/winforms/и т.д.
нужны _нормальные_ средства для обмена данными с сервером. И всё это будет… когда-нибудь :)
а до тех пор — так и будут делаться новые костыли
Камрад просто сформулировал общие принципы создания 3-tier приложений на базе обычной веб-инфраструктуры.
разумеется видел. Больше того, я уже несколько лет, как вынужден использовать эти крайне ограниченные средства для разработки чего-то похожего на rich user interface. Просто у нас с вами разные понятия о rich user interface :)
я вижу, как используется куча костылей (ГОРА костылей), чтобы на основе html/css/js собирать обычные виджеты, которые и так есть в любой современной ОС. Есть конечно и интересные находки, но это капли в море
я вижу, как используется куча костылей (ГОРА костылей), чтобы на основе html/css/js собирать обычные виджеты, которые и так есть в любой современной ОС. Есть конечно и интересные находки, но это капли в море
Спасибо за ваш комментарий. Я согласен, что с возможностями Flash/Flex JavaScript, на данном этапе не сможет тягаться, но я не зря привел несколько примеров поддержки языка со стороны крупных компаний. Для js порог вхождения ниже, чем для As2/As3. К тому же, из моего опыта, большинство задач легко решается на чистом js без сторонних технологий, разве что с графиками проблема, да и то уже есть замечательные работающие решения. Плюс, работа клиентского приложения только с протоколом позволит вам изменить его не трогая сервера, в случае, если станет необходимым переход на нативное приложение для десктопа или на тот же flash.
Стандарты действительно нужно развивать. Думаю лет так через нцать, это все выльется в тонкие клиенты и платформа на них будет крутиться иная.
Спасибо за статью — хороша.
Это действительно не MVC никоим боком, как народ верно заметил. Это multitier (3-tier) система из DB server, application server и client.
Это действительно не MVC никоим боком, как народ верно заметил. Это multitier (3-tier) система из DB server, application server и client.
Спасибо за совет, я хотел утрировано показать на схожесть с очень абстрактной MVC, но пожалуй, вышло невнятно.
У меня сейчас как раз обдумывается проект, который будет иметь примерно такую архитектуру.
Так что очень вовремя :-)
А в свете MVC на самом деле интересно рассмотреть архитектуру клиентской части.
Application Server, правда, скорее всего будет на Delphi писаться, потому для передачи данных AS<->client будет использован XML.
Так что очень вовремя :-)
А в свете MVC на самом деле интересно рассмотреть архитектуру клиентской части.
Application Server, правда, скорее всего будет на Delphi писаться, потому для передачи данных AS<->client будет использован XML.
Очень прогрессивная архитектура: клиент, сервер и http. Мы тоже используем её на работе, на особо прогрессивных проектах — все рекомендую! И AJAX (с методами, см. выше) тоже обязательно нужен, чтобы было круто.
И JSON это мега-прогрессивно, оказывается, мы можем хранить данные прямо в JavaScript, хотя программисты мне говорили, что данные надо хранить только в XML — больше не буду им верить.
И JSON это мега-прогрессивно, оказывается, мы можем хранить данные прямо в JavaScript, хотя программисты мне говорили, что данные надо хранить только в XML — больше не буду им верить.
Это типа шутка юмора?
Зачем так уныло троллить? Если вы не согласны с каким-либо утверждениями, опишите пожалуйста в нормальной форме.
ООП в js есть, в другой форме, но есть. Официально. Или у вас есть спецификация iso на то, что называть ООП-языком, а что нет?
Чем вам http не понравился? Достаточно надежный протокол, а в контексте RIA вообще хорош — не нужно возни с сокетами, нужно думать о пулах соединений и т.д. Тем более, нет нужды писать свои велосипеды и по пол года их отлаживать — все уже написано и отлажено коммьюнити.
Написал, хотя вступать с вами в спор в такой форме не намерен, вы бы для начала статью внимательно прочитали.
ООП в js есть, в другой форме, но есть. Официально. Или у вас есть спецификация iso на то, что называть ООП-языком, а что нет?
Чем вам http не понравился? Достаточно надежный протокол, а в контексте RIA вообще хорош — не нужно возни с сокетами, нужно думать о пулах соединений и т.д. Тем более, нет нужды писать свои велосипеды и по пол года их отлаживать — все уже написано и отлажено коммьюнити.
Написал, хотя вступать с вами в спор в такой форме не намерен, вы бы для начала статью внимательно прочитали.
Добрый вечер. Статья, как я её понял: история создания скрипта (без упоминания экмы), область применение скрипта (с двумя браузерами, без ОС и прочего), трюки с функциями (зачем это надо, есть же куча статей и сайтов, даже на русском), что такое http и как с ним бороться (иллюстрация милая, но, плиз, напишите вместо «JSON» — «Запрос» или «AJAX», если угодно), сайт это конечное кол-во функционала (аспект), база данных позволяет хранить данные, мы можем отправить запрос когда надо и, получив ответ, поменять DOM (причем тут «машина»?).
Понимаете, статья, ниочем просто. Идея, ход мыслей, целостность — где они? Я бы не узнал что такое скрипт, где и как он применяется, не научился бы работать с БД и не понял бы, почему аяксом нельзя подставлять шапку/подвал на каждую страницу. У любого такого обозрения должна быть самодостаточность, лучше бы написали «Ребята, кидаться JSON'он круто!» — и все.
Но сделать такое обозрение, безусловно, Ваше право. Почему бы не назвать его «Мир AJAX?» Причем тут паттерны, сколько еще нужно статей, чтобы человек (толи имеющий некий опыт, толи далекий от веб-технологий) написал своё Rich Internet Applications, ну или клиентскую, или серверную часть?
Да и ладно бы это все, уныло троллить я начал после восторженных возгласов: «Спасибо за статью!», «Очень много узнал», «Мы тоже используем JSON», «Мы тоже используем JSON, но у меня не JSON, а XML». Что все эти люди узнали нового?
Понимаете, статья, ниочем просто. Идея, ход мыслей, целостность — где они? Я бы не узнал что такое скрипт, где и как он применяется, не научился бы работать с БД и не понял бы, почему аяксом нельзя подставлять шапку/подвал на каждую страницу. У любого такого обозрения должна быть самодостаточность, лучше бы написали «Ребята, кидаться JSON'он круто!» — и все.
Но сделать такое обозрение, безусловно, Ваше право. Почему бы не назвать его «Мир AJAX?» Причем тут паттерны, сколько еще нужно статей, чтобы человек (толи имеющий некий опыт, толи далекий от веб-технологий) написал своё Rich Internet Applications, ну или клиентскую, или серверную часть?
Да и ладно бы это все, уныло троллить я начал после восторженных возгласов: «Спасибо за статью!», «Очень много узнал», «Мы тоже используем JSON», «Мы тоже используем JSON, но у меня не JSON, а XML». Что все эти люди узнали нового?
Zitrix, спасибо Вам за конструктивную критику. Я не ставил перед собой цель сразу написать учебник «от основ js до написания RIA», просто привел обзор возможностей js в контексте построения RIA, те люди, которых заинтересовало, разумеется, сами будут двигаться дальше. Если бы я пол года назад наткнулся на похожую статью, то не сделал бы столько ошибок, хотя бы, уже имел некоторое представление. Даже если идея лежит на поверхности, не всем она приходит в голову сразу, в том числе и мне, а похожих материалов я не видел, к сожалению. Да, признаю, статья несколько поверхностная, но это же популяризация подхода, а не справочник!
Ну раз такое дело, то извините, RIA действительно надо двигать в массы.
Ничего страшного, вы были правы со своей точки зрения — для серьезного учебника содержание статьи оценивать можно с точки зрения профанации идеи. Однако, если статью прочитает менеджер, к примеру, ему суть будет так же понятна, как и программисту, пускай последний будет кривить лицо на некоторые мои пассажи.
Спасибо за статью. Буду ждать следующих.
Великолепная статья! Спасибо Вам огромное!
И я благодарю за очень интересную статью!
надеюсь, продолжение будет?
надеюсь, продолжение будет?
Ничего нового для себя из статьи не вынес. Может она будет интересна новичкам, которые ещё не наступали на грабельки, разложенные якобы стандартом JavaScript (ECMAScript) тут и там для разных браузеров. Но RIA на AJAX в браузере — это слишком рискованный и неблагодарный труд для тестеров.
Спустя вот уже тринадцать лет все почему-то решительно забыли про Java-апплеты и ActiveX-формы, которые по-настоящему являются RIA. Используют нативные виджеты операционной/оконной системы и у них гораздо выше уровень юзабельности (нет раздражающих подтормаживаний в реакции интерфейса на действия пользователя).
Но Java-апплеты не прижились по причине ограниченной совместимости встроенной в IE версии MS JVM и гораздо более функциональной Sun JVM (которую нужно ещё загрузить и установить, дистрибутив ~15МБ): для последней пишутся апплеты быстрее всего, для первой нужно с апплетом таскать собственные библиотеки.
ActiveX-формы, в отличие от Java-апплетов, потенциально небезопасны и открывают всю систему клиента внешнему миру (точно так же, как если бы клиент запускал стороннее приложение). ActiveX работают только на Windows (впрочем, последнее не так важно).
Итак, то, с чем заморачиваются при разработке в AJAX, давно доступно, что называется, «из коробки» в каждой из этих технологий в виде готовых фреймворков, идущих в комплекте с рантаймом и/или в составе операционной системы. И REST использовался в апплетах с незапамятных времён, обмен «отсоединёнными» данными между тонкими клиентами и СУБД через апплеты вёлся со времени их представления миру.
Вот появился WebKit. Интерпретативная природа JavaScript'а постепенно меняется на JIT (Just In Time Compiler). Это похвально, что интерпретируемый язык приобретает черты компилируемого, избавляясь от «медлительности и задумчивости». Но это не умаляет его главного недостатка: неверифицируемости кода языка в контенте, отдаваемой клиенту. Малейший сбой передачи (а протокол http является ненадёжным по своей природе) подвергает сомнению проведение транзакций через AJAX-компоненты под управлением JavaScript.
Спустя вот уже тринадцать лет все почему-то решительно забыли про Java-апплеты и ActiveX-формы, которые по-настоящему являются RIA. Используют нативные виджеты операционной/оконной системы и у них гораздо выше уровень юзабельности (нет раздражающих подтормаживаний в реакции интерфейса на действия пользователя).
Но Java-апплеты не прижились по причине ограниченной совместимости встроенной в IE версии MS JVM и гораздо более функциональной Sun JVM (которую нужно ещё загрузить и установить, дистрибутив ~15МБ): для последней пишутся апплеты быстрее всего, для первой нужно с апплетом таскать собственные библиотеки.
ActiveX-формы, в отличие от Java-апплетов, потенциально небезопасны и открывают всю систему клиента внешнему миру (точно так же, как если бы клиент запускал стороннее приложение). ActiveX работают только на Windows (впрочем, последнее не так важно).
Итак, то, с чем заморачиваются при разработке в AJAX, давно доступно, что называется, «из коробки» в каждой из этих технологий в виде готовых фреймворков, идущих в комплекте с рантаймом и/или в составе операционной системы. И REST использовался в апплетах с незапамятных времён, обмен «отсоединёнными» данными между тонкими клиентами и СУБД через апплеты вёлся со времени их представления миру.
Вот появился WebKit. Интерпретативная природа JavaScript'а постепенно меняется на JIT (Just In Time Compiler). Это похвально, что интерпретируемый язык приобретает черты компилируемого, избавляясь от «медлительности и задумчивости». Но это не умаляет его главного недостатка: неверифицируемости кода языка в контенте, отдаваемой клиенту. Малейший сбой передачи (а протокол http является ненадёжным по своей природе) подвергает сомнению проведение транзакций через AJAX-компоненты под управлением JavaScript.
Спасибо за потраченное время.
Java апплеты научились использовать нативные виджеты далеко не сразу, если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash. ActiveX лично я бы не использовал даже на Windows — тяжело разрабатывать и поддерживать приложения, да и смысла тогда делать RIA не вижу совершенно, лучше уже нативный клиент. Чем же вам http не угодил, я не знаю, он такой же «ненадежный», как и все другие протоколы, что базируются на TCP/IP.
«Заморочки» при использовании Ajax канули в лету, когда XMLHTTPRequest стали поддерживать все основные браузеры. Сейчас полно библиотек, оттестированых огромным сообществом, позволяющим производить запрос в виде
var answer = Ajax.query(); с обработкой всех событий до-, во время и после загрузки данных.
Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать? Я на практике убедился, что тестировать ее если не проще, то по крайней мере не сложнее тестирования обычного приложения. Мы конечно говорим о тестировании с помощью человека?
Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
Java апплеты научились использовать нативные виджеты далеко не сразу, если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash. ActiveX лично я бы не использовал даже на Windows — тяжело разрабатывать и поддерживать приложения, да и смысла тогда делать RIA не вижу совершенно, лучше уже нативный клиент. Чем же вам http не угодил, я не знаю, он такой же «ненадежный», как и все другие протоколы, что базируются на TCP/IP.
«Заморочки» при использовании Ajax канули в лету, когда XMLHTTPRequest стали поддерживать все основные браузеры. Сейчас полно библиотек, оттестированых огромным сообществом, позволяющим производить запрос в виде
var answer = Ajax.query(); с обработкой всех событий до-, во время и после загрузки данных.
Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать? Я на практике убедился, что тестировать ее если не проще, то по крайней мере не сложнее тестирования обычного приложения. Мы конечно говорим о тестировании с помощью человека?
Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
>Java апплеты научились использовать нативные виджеты далеко не сразу
Ну откуда такая неосведомлённость? Первые Java-апплеты запускались на заре браузеростроения — ещё в примитивном Mosaic. Это было основным предназначением Java как языка после его представления широкой публике в 1995 году. Библиотека AWT, использующая нативные виджеты оконной системы, была разработана буквально за месяц-полтора, чтобы предоставить программистам API для создания работающих приложений.
>если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash.
NetBeans со встроенным дизайнером Matisse — прекрасный образец бесплатного визуального редактора для создания GUI на Java. Чем же оно хуже Flash? Я думаю, своей сложностью и нехватной времени дизайнерам осваивать новый инструмент (скорее, не-)дизайна и программирования.
>«Заморочки» при использовании Ajax канули в лету
Несовсем. Тематические страницы Хабра не совсем корректно обновляются, если клиент находится за прокси-сервером, который [прокси] имеет политики защиты от спама, флуда (множественных сетевых запросов) и т.д. Мне, например, приходится часто просто перезагружать страницы.
>Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать?
Слишком много уровней (программных) на пути между клиентом и сервером. Между уровнями есть точки «затыка», где передаваемяе данные пропускаются фильтрами словно через бутылочное горлышко, а программный код JavaScript интерпретируется иногда по-разному.
>Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
Не сомневаюсь в этом.
Ну откуда такая неосведомлённость? Первые Java-апплеты запускались на заре браузеростроения — ещё в примитивном Mosaic. Это было основным предназначением Java как языка после его представления широкой публике в 1995 году. Библиотека AWT, использующая нативные виджеты оконной системы, была разработана буквально за месяц-полтора, чтобы предоставить программистам API для создания работающих приложений.
>если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash.
NetBeans со встроенным дизайнером Matisse — прекрасный образец бесплатного визуального редактора для создания GUI на Java. Чем же оно хуже Flash? Я думаю, своей сложностью и нехватной времени дизайнерам осваивать новый инструмент (скорее, не-)дизайна и программирования.
>«Заморочки» при использовании Ajax канули в лету
Несовсем. Тематические страницы Хабра не совсем корректно обновляются, если клиент находится за прокси-сервером, который [прокси] имеет политики защиты от спама, флуда (множественных сетевых запросов) и т.д. Мне, например, приходится часто просто перезагружать страницы.
>Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать?
Слишком много уровней (программных) на пути между клиентом и сервером. Между уровнями есть точки «затыка», где передаваемяе данные пропускаются фильтрами словно через бутылочное горлышко, а программный код JavaScript интерпретируется иногда по-разному.
>Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
Не сомневаюсь в этом.
Спасибо за критику и простите меня за неосведомленность, я имел ввиду SWT.
Про «заморочки» я говорил с точки зрения программиста. Можно вообще закрыть 80 порт и тогда утверждать, что http — замороченый протокол (простите за пример). Опять же, дальнейший затык — тоже проблема администрирования сети, а никак не разработки и тестирования. А программные уровни — как раз плата за независимость клиента от сервера.
Про «заморочки» я говорил с точки зрения программиста. Можно вообще закрыть 80 порт и тогда утверждать, что http — замороченый протокол (простите за пример). Опять же, дальнейший затык — тоже проблема администрирования сети, а никак не разработки и тестирования. А программные уровни — как раз плата за независимость клиента от сервера.
«Малейший сбой передачи (а протокол http является ненадёжны...» на мой взгляд это не проблема яваскрипта.
то проблема хттп, а точнее того, что пакеты теряются и будут теряться изза особенностей работы интернет.
другое дело, что разработчик может написать систему отлова и обработки ошибок так, чтобы это не вредило работоспособности системы в целом.
п.с. автору огромное спасибо за статью
то проблема хттп, а точнее того, что пакеты теряются и будут теряться изза особенностей работы интернет.
другое дело, что разработчик может написать систему отлова и обработки ошибок так, чтобы это не вредило работоспособности системы в целом.
п.с. автору огромное спасибо за статью
Соглашусь со многими уже прозвучавшими мнениями, но в статье нет логики. Заголовок сам по себе спорен, термин «Ajax-машина» отнюдь нетривиален на мой взгляд. Пол статьи читал про javascript и как на нем писать, как будто это что-то новое. На мой взгляд можно было ограничиться ссылкой на пару-тройку статей о javascript и не более (хотя я бы вообще выкинул такие подробности). Потом я порадовался что «Ajax-машина» — это паттерн реализующий 3-х звенную архитектуру, MVC в простонародьи. Но JSON как-то вообще не тянет на буковку C в аббревиатуре! Понятие «Аспекты» для меня тоже новое, сколько книжек не читал такого не вычитал… Много ляпов, не знание терминологии. Для новичков эта статья просто опасна! Язло!
Вот бы мне так научиться излагать свои мысли. Хотел попридираться, но право же, грешно.
Примеры немного странные.
«Функцию можно вызвать с произвольным количеством аргументов» подразумевает также случай, когда и без аргументов совсем! (Зачем тогда второй пример?)
«Функция, как объект первого рода» — поправьте на «объект первого класса», пожалуйста. Кстати, не показано, что функции можно также и возвращать из функций (а не только передавать в качестве аргументов).
«Динамическое изменение объектов» следует из нестрогой динамической типизации.
В общем, более последовательнее надо бы, типа как здесь: www.smlnj.org/sml.html
«Функцию можно вызвать с произвольным количеством аргументов» подразумевает также случай, когда и без аргументов совсем! (Зачем тогда второй пример?)
«Функция, как объект первого рода» — поправьте на «объект первого класса», пожалуйста. Кстати, не показано, что функции можно также и возвращать из функций (а не только передавать в качестве аргументов).
«Динамическое изменение объектов» следует из нестрогой динамической типизации.
В общем, более последовательнее надо бы, типа как здесь: www.smlnj.org/sml.html
> Зачем тогда второй пример?
Просто так ;)
> Функция, как объект первого рода
поправил, хотя слышал два варианта употребления
> Кстати, не показано, что функции можно также и возвращать из функций
А пример замыканий?
Просто так ;)
> Функция, как объект первого рода
поправил, хотя слышал два варианта употребления
> Кстати, не показано, что функции можно также и возвращать из функций
А пример замыканий?
>> Функция, как объект первого рода
>поправил, хотя слышал два варианта употребления
Ваш вариант слышу в первый раз, скиньте ссылку, пожалуйста.
>А пример замыканий?
Замыкания — отдельно, анонимные функции — отдельно. :)
Пример:
var addEvent = (function() {
/*
тут не обращаем внимание на название функций, зато обращаем внимание на staging computation
*/
return msie? attachEvent: addEvent;
})();
Замыкания тут нет.
PS в целом: так держать! :)
>поправил, хотя слышал два варианта употребления
Ваш вариант слышу в первый раз, скиньте ссылку, пожалуйста.
>А пример замыканий?
Замыкания — отдельно, анонимные функции — отдельно. :)
Пример:
var addEvent = (function() {
/*
тут не обращаем внимание на название функций, зато обращаем внимание на staging computation
*/
return msie? attachEvent: addEvent;
})();
Замыкания тут нет.
PS в целом: так держать! :)
Ссылок к сожанию не дам, слышал 2 варианта от разных людей. Я не переводчик, поэтому не знаю, first class object лучше переводить дословно или нет :) Пример с анонимными функциями добавлю чуть попозже :)
Не переживайте. В том контексте, как вы подали, можно использовать higher-order functions (функции высшего порядка) или функции, принимающие и/или возвращающие другую функцию, ваш пример как раз об этом. Что касается немного чужеродного для javascript-a термина first-class objects/first-class citizens (объекты первого/первичного класса), чем обычно подчёркивается равноправие функций с другими значениями, то тут так просится пример с простым добавлением функции свойства (наследуемого или своего, не важно).
>Замыкания тут нет.
К слову, есть давняя и поддерживаемая многими позиция, что все функции в javascript-е — замыкания уже по факту рождения. Что анонимные, что именованные… ;)
К слову, есть давняя и поддерживаемая многими позиция, что все функции в javascript-е — замыкания уже по факту рождения. Что анонимные, что именованные… ;)
мне написанная схема очень напоминает GWT. Правда, балансировщиков там нет. Но это лишь вопрос требований и конфигурации
Василий Помидоров порадовал — это вам не банальный Василий Пупкин!
Спасибо за статью.
Спасибо за статью.
Спасибо за статью, весьма познавательная и очень легко читалась. Понравились шутки в примерах :)
Хороша статья.
Но остается вопрос. Не слишком ли накладно всю структуру делать на стороне клиента? Если проект большой, то на клиента ложится уж больно много функционала и всей JS обертки, что собственно отрицательно может сказаться на производительности такого подхода.
Но остается вопрос. Не слишком ли накладно всю структуру делать на стороне клиента? Если проект большой, то на клиента ложится уж больно много функционала и всей JS обертки, что собственно отрицательно может сказаться на производительности такого подхода.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ajax-машина