Спасибо за ответ. Я старался подбирать простые аналогии. Понятие аспект для данной статьи искусственное, я вводил его специально для упрощения описания.
Спасибо за критику и простите меня за неосведомленность, я имел ввиду SWT.
Про «заморочки» я говорил с точки зрения программиста. Можно вообще закрыть 80 порт и тогда утверждать, что http — замороченый протокол (простите за пример). Опять же, дальнейший затык — тоже проблема администрирования сети, а никак не разработки и тестирования. А программные уровни — как раз плата за независимость клиента от сервера.
Zitrix, спасибо Вам за конструктивную критику. Я не ставил перед собой цель сразу написать учебник «от основ js до написания RIA», просто привел обзор возможностей js в контексте построения RIA, те люди, которых заинтересовало, разумеется, сами будут двигаться дальше. Если бы я пол года назад наткнулся на похожую статью, то не сделал бы столько ошибок, хотя бы, уже имел некоторое представление. Даже если идея лежит на поверхности, не всем она приходит в голову сразу, в том числе и мне, а похожих материалов я не видел, к сожалению. Да, признаю, статья несколько поверхностная, но это же популяризация подхода, а не справочник!
Зачем так уныло троллить? Если вы не согласны с каким-либо утверждениями, опишите пожалуйста в нормальной форме.
ООП в js есть, в другой форме, но есть. Официально. Или у вас есть спецификация iso на то, что называть ООП-языком, а что нет?
Чем вам http не понравился? Достаточно надежный протокол, а в контексте RIA вообще хорош — не нужно возни с сокетами, нужно думать о пулах соединений и т.д. Тем более, нет нужды писать свои велосипеды и по пол года их отлаживать — все уже написано и отлажено коммьюнити.
Написал, хотя вступать с вами в спор в такой форме не намерен, вы бы для начала статью внимательно прочитали.
Спасибо за потраченное время.
Java апплеты научились использовать нативные виджеты далеко не сразу, если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash. ActiveX лично я бы не использовал даже на Windows — тяжело разрабатывать и поддерживать приложения, да и смысла тогда делать RIA не вижу совершенно, лучше уже нативный клиент. Чем же вам http не угодил, я не знаю, он такой же «ненадежный», как и все другие протоколы, что базируются на TCP/IP.
«Заморочки» при использовании Ajax канули в лету, когда XMLHTTPRequest стали поддерживать все основные браузеры. Сейчас полно библиотек, оттестированых огромным сообществом, позволяющим производить запрос в виде
var answer = Ajax.query(); с обработкой всех событий до-, во время и после загрузки данных.
Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать? Я на практике убедился, что тестировать ее если не проще, то по крайней мере не сложнее тестирования обычного приложения. Мы конечно говорим о тестировании с помощью человека?
Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
Спасибо за ваш комментарий. Я согласен, что с возможностями Flash/Flex JavaScript, на данном этапе не сможет тягаться, но я не зря привел несколько примеров поддержки языка со стороны крупных компаний. Для js порог вхождения ниже, чем для As2/As3. К тому же, из моего опыта, большинство задач легко решается на чистом js без сторонних технологий, разве что с графиками проблема, да и то уже есть замечательные работающие решения. Плюс, работа клиентского приложения только с протоколом позволит вам изменить его не трогая сервера, в случае, если станет необходимым переход на нативное приложение для десктопа или на тот же flash.
Новичок в RIA не обязательно новенький в программировании вообще. К примеру, если он хочет получить легкий в разработке кроссплатформенный тонкий клиент для уже существующей системы, то RIA будет отличным решением, по моему мнению. Сожалею, что мой стиль заставил потратить ваше время.
Всю важную информацию можно передавать в защищенном виде через http только с приставкой s. Пожалуйста, не смотрите на предложенный мною подход, как на что-то новое, это, по сути, обычный сайт, посаженый на js-стероиды и отделенный наглухо от серверной части протоколом.
Ситуация один в один схожа с любым другим сайтом или приложением, работающим через сеть — перехватить и модифицировать можно любые пакеты, вопрос в том, что сделали авторы данного приложения, что бы обезопасить пользователя. Передают ли критичные данные через защищенные соединения, например.
Если Вася Помидоров попытается получить права СуперАдмина, а владеет только правами СреднегоЮзера, то сколько бы он не слал модифицированных пакетов на сервер, тот равнодушно позволит менять ему данные только от имени СреднегоЮзера, да еще и забанить может за такое :)
Клиент в руках врага :) Вам по сути, никто не помешает модифицировать код Хабра у себя в браузере, к примеру добавить своему другу 1 000 000 кармы. Однако, на сервере ваш запрос на миллион кармы будет отклонен, разумеется. Тут идентичная ситуация — все ваши хаки будут распространены только на клиент, а сервер их просто отбросит.
Блокировка функций — следствие идеологии паттерна, которая гласит, что клиент должен сразу иметь весь функциональный код при загрузке.
Спасибо за уточнение, я постарался привести краткое описание в первую очередь для людей, которые не знакомы с js или малознакомы с ним. К сожалению, узкие рамки фомата статьи не позволяют концентрировать внимание на таких тонкостях.
Мне кажется, что отдавать даже несжатый css и js код клиенту за один раз проще, чем добавлять к клиенту и серверу функциональность по их подгрузке. К тому же, это нарушит чистоту архитектуры, одним из условий которой является зависимость клиента и сервера только от протокола обмена, а не друг от друга. Ведь по сути, сервер может работать без изменений в коде с любым клиентом, не только базирующимся на html+css+js, к примеру, это может быть flash.
Прошу прощения, если ввел вас в заблуждение упоминанием MVC, я хотел на примере популярного паттерна показать абстрактную структуру для описываемого приложения. Разумеется, данным от клиента доверять не стоит вообще, однако, для удобства пользователя, проверки и уведомления об ошибках валидации на стороне клиента все же необходимы. Если вы не хотите дублировать функционал, можете воспользоваться предложенным в этой статье способом обработки ошибок ;)
Пожалуйста, мне приятно, что вам понравилось. Что до остального, то времени вообще не хватает, очень жалко. Эту статью еще в августе готовил, да вот времени не хватало. Может быть у кого-то из хабравчан будет больше свободного времени, вот и поделятся опытом с нами :)
Спасибо за совет, забывать не собираюсь, хотя ни денег особых, ни команды, ни даже кучи свободного времени у меня нет и в ближайшем будущем не будет. Зато у меня есть хорошие идеи для реализации и немного времени по вечерам. Всегда были и до сих пор есть люди, которые вдвоем-втроем делают хорошие игры. Да ладно игры, у истоков многих больших компаний стояли несколько небогатых человек, за примерами достаточно глянуть направо в блок «Компании». Даже если у меня ничего не выйдет (я достаточно трезво оцениваю ситуацию), я сам ничего не потеряю, рисков никаких, но приобрету ценный опыт, в любом случае.
Не бойтесь :) После падения доткомов тоже было страшно, страх — препятствие для новых идей, провальных и гениальных.
А в качестве офтопа, можно парочку вопросов, uaperson? :)
Задам:
— Как вы решаете проблему мультиводства, игры несколькими персонажами с одного аккаунта, с целью усилить своего основного?
— Как вы защищаетесь от ботов?
Если не секрет, конечно.
Про «заморочки» я говорил с точки зрения программиста. Можно вообще закрыть 80 порт и тогда утверждать, что http — замороченый протокол (простите за пример). Опять же, дальнейший затык — тоже проблема администрирования сети, а никак не разработки и тестирования. А программные уровни — как раз плата за независимость клиента от сервера.
ООП в js есть, в другой форме, но есть. Официально. Или у вас есть спецификация iso на то, что называть ООП-языком, а что нет?
Чем вам http не понравился? Достаточно надежный протокол, а в контексте RIA вообще хорош — не нужно возни с сокетами, нужно думать о пулах соединений и т.д. Тем более, нет нужды писать свои велосипеды и по пол года их отлаживать — все уже написано и отлажено коммьюнити.
Написал, хотя вступать с вами в спор в такой форме не намерен, вы бы для начала статью внимательно прочитали.
Java апплеты научились использовать нативные виджеты далеко не сразу, если судить по сложности разработки именно клиентских интерфесов — java не самое приятное решение как для пользователя, так и для программиста, много лучше уже Flash. ActiveX лично я бы не использовал даже на Windows — тяжело разрабатывать и поддерживать приложения, да и смысла тогда делать RIA не вижу совершенно, лучше уже нативный клиент. Чем же вам http не угодил, я не знаю, он такой же «ненадежный», как и все другие протоколы, что базируются на TCP/IP.
«Заморочки» при использовании Ajax канули в лету, когда XMLHTTPRequest стали поддерживать все основные браузеры. Сейчас полно библиотек, оттестированых огромным сообществом, позволяющим производить запрос в виде
var answer = Ajax.query(); с обработкой всех событий до-, во время и после загрузки данных.
Поясните пожалуйста, почему предложенную мной архитектуру тяжело тестировать? Я на практике убедился, что тестировать ее если не проще, то по крайней мере не сложнее тестирования обычного приложения. Мы конечно говорим о тестировании с помощью человека?
Более того, я хочу отметить, что разрабатывать стало гораздо удобнее, да и писать юнит-тесты с моками — просто сказочно удобно, благо протокол описан.
Если Вася Помидоров попытается получить права СуперАдмина, а владеет только правами СреднегоЮзера, то сколько бы он не слал модифицированных пакетов на сервер, тот равнодушно позволит менять ему данные только от имени СреднегоЮзера, да еще и забанить может за такое :)
Блокировка функций — следствие идеологии паттерна, которая гласит, что клиент должен сразу иметь весь функциональный код при загрузке.
А в качестве офтопа, можно парочку вопросов, uaperson? :)
Задам:
— Как вы решаете проблему мультиводства, игры несколькими персонажами с одного аккаунта, с целью усилить своего основного?
— Как вы защищаетесь от ботов?
Если не секрет, конечно.