Comments 37
Сразу же к самому началу статьи комментарий:
С технической точки зрения существовало только одно решение для того, чтобы «подружить» эти приложения, — применить HTML-фреймы
А что, SOAP или XML-RPC нынче не в моде?
Или, например, я когда-то писал свою XML-RPC-подобную систему интеграции веб-сервисов, которая не требовала почти ничего (а при должной заточке под конкретные ресурсы — вообще ничего) от сервисов-«доноров».
И реализация крайне простая.
Уж о чем-чем, а про iFrame я бы в последнюю очередь думал
С технической точки зрения существовало только одно решение для того, чтобы «подружить» эти приложения, — применить HTML-фреймы
А что, SOAP или XML-RPC нынче не в моде?
Или, например, я когда-то писал свою XML-RPC-подобную систему интеграции веб-сервисов, которая не требовала почти ничего (а при должной заточке под конкретные ресурсы — вообще ничего) от сервисов-«доноров».
И реализация крайне простая.
Уж о чем-чем, а про iFrame я бы в последнюю очередь думал
Это был 12 лет назад. О существовании SOAP и XML-RPC я тогда еще даже не слышал. Система писалась на Perl… Тег IFrame так же позволял показывать MS Word и MS Excel документы, а так же изображения.
С каких это пор браузеры научились показывать ворды-эксели?
Боюсь ошибиться, по моему с IE4 или IE5. У Microsoft тогда появилась концепция, что их браузер должен иметь возможность отображения офисных документов, если сам офис или соответствующие просмотрщики установлены на компьютере.
а не подскажете, в каких броузерах CORS работает?
я релиза таких пока не встречал
я релиза таких пока не встречал
Начиная с MF 3.5 (https://developer.mozilla.org/en/HTTP_access_control), в IE8 есть свой объект (http://magmainteractive.net/weblogs/post/Internet-Explorer-8-and-Cross-domain-Requests.aspx).
последний линк о XDomainRequest не поддерживается, я нашел новый: msdn.microsoft.com/en-us/library/cc288060%28v=vs.85%29.aspx
Не, какое-то это костыльное решение.
Крос-доменность — сплошные костыли. Стандарт-то есть, но его поддержка весьма туманна. А учитывая то что в большинстве случаев корп. сети сидят в экосистеме Microsoft и браузер там — IE (хорошо если свежий), то вообще беда.
А контроль доступа? Роли? Интеграция с Active Directory (раз уж это Enterprise сегмент)? И еще сотни вопросов.
Нельзя такие вещи переносить на яваскрипт, нельзя.
SOAP, XML-RPC или схожая собственная реализация на curl-ах или сокетах для получения данных из сервисов и вся бизнес-логика на сервере портала.
Вариантов масса.
Крос-доменность — сплошные костыли. Стандарт-то есть, но его поддержка весьма туманна. А учитывая то что в большинстве случаев корп. сети сидят в экосистеме Microsoft и браузер там — IE (хорошо если свежий), то вообще беда.
А контроль доступа? Роли? Интеграция с Active Directory (раз уж это Enterprise сегмент)? И еще сотни вопросов.
Нельзя такие вещи переносить на яваскрипт, нельзя.
SOAP, XML-RPC или схожая собственная реализация на curl-ах или сокетах для получения данных из сервисов и вся бизнес-логика на сервере портала.
Вариантов масса.
Terion, крос-доменность нужна для построения машапов и технологиям SOAP и XML-RPC там нет места. Машапы это Web 2.0 решения основанные на Ajax. Я понимаю вашу озабоченность вопросами безопасности. Именно поэтому в статье я указал, что секурити модуль еще не готов именно потому, что я тоже вижу некоторые проблемы. Лично мне нравится пока использовать обычный прокси. Я внимательно наблюдаю за развитием ситуации с CORS и как только все будет хорошо, я сделаю CORS в качестве основного решения. Я просто буду готов. Это то как в рекламе, вы не должны, но вы в принципе можете…
«крос-доменность нужна для...»
Я не говорю что она не нужна, я говорю, что в яваскрипте это реализовывается через задницу, из-за проблем со стандартами и их поддержкой.
ничто не мешает пропускать все через сервер и делать эти ваши мЭшапы с использованием серверных технологий, которые будут контролировать данные и доступы
Я не говорю что она не нужна, я говорю, что в яваскрипте это реализовывается через задницу, из-за проблем со стандартами и их поддержкой.
ничто не мешает пропускать все через сервер и делать эти ваши мЭшапы с использованием серверных технологий, которые будут контролировать данные и доступы
Terion, я же и в статье и в ответах написал, что можно и мне нравится использование proxy в Ajax Portal. Но у этого подхода повышается нагрузка на портальный сервер. При использовании крос-доменных запросов: 1) снижается нагрузка на портальный сервер 2) ускоряется загрузка контента 3) нет необходимости тотального использования кешей для блокировки лавинного возрастания ретранслируемого контента через портальный сервер. Это всеравно будет сделано — это следующий шаг эволюции и переход к распределенным системам. Путь текущая версия CORS неидеальна. Следующая версия будет лучше.
а почему просто не использовать, к примеру, extJS? в коем можно написать свои store под нужный api? да и концепция «портлетов» на него тоже легко ложится
ну и кросс доменность там тоже легко реализуется через Ext.data.ScriptTagProxy
На сколько я знаю, extJS не является бесплатной. Вы готовы платить 500 баксов или на 500 больше за одну девелоперскую лицензию? С другой стороны, если вы готовы платить и у вас есть покупатели — можем договориться (я вполне серьезно).
екста (а ныне сенча) платная, да, но там это все уже реализовано, по сути.
Взяли бы джейквери и сократили бы себе объем работы в десятки раз.
Взяли бы джейквери и сократили бы себе объем работы в десятки раз.
Осваивать можно и бесплатно. А при запуске Корпоративного портала со всякими наворотами заплатить 500 баксов.
Статья как бы намекает на сложные разработки, а что такое 500 баксов относительно при нескольких месяцах разработки энтерпрайз софта?
Статья как бы намекает на сложные разработки, а что такое 500 баксов относительно при нескольких месяцах разработки энтерпрайз софта?
Продукт только выходит из альфы в бету. До тех пор пока проект не выйдет на самоокупаймость я буду воздерживаться от использования платных решений. Исключение может быть сделано, только при наличии спонсора или если инициатором является владелец(ы) JS-фреймворка.
Причём тут альфа, бета, гамма?
Вам за продукт не платят(вы на нём не зарабатываете)? Тогда и за использование extJS платить не надо
Вам за продукт платят? Вот тогда можно и нужно заплатить
Вам за продукт не платят(вы на нём не зарабатываете)? Тогда и за использование extJS платить не надо
Вам за продукт платят? Вот тогда можно и нужно заплатить
Пока проект не зарабатывает денег ничего платить не надо. Или цена продукта сравнима с 500$ что не позволяет с одной продажи его купить?
Интересно во сколько вы оцениваете час своей работы и сколько часов Вы планируете потратить на свой продукт + будущая стоимость продукта. Ну чтоб прикинуть процент от 500 баксов
Интересно во сколько вы оцениваете час своей работы и сколько часов Вы планируете потратить на свой продукт + будущая стоимость продукта. Ну чтоб прикинуть процент от 500 баксов
Стоимость первых продаж не связана со стоимостью моего рабочего времени.
Вдогонку:
Если родительское и дочернее окно находятся в пределах одного домена (включая его поддомены) то сайзятся фреймы на «ура». Ну это так, на заметку.
При использовании ajax4all в Ajax Portal появляется возможность естественного заполнения контентом выделенной области и пропорциональной растяжке ее по вертикали, именно то, что не может быть достигнуто при использовании HTML-тега IFrame.
Если родительское и дочернее окно находятся в пределах одного домена (включая его поддомены) то сайзятся фреймы на «ура». Ну это так, на заметку.
Ах, и еще:
«зааяксивание» форм (любых форм и без потери функциональности) на любом аякс-фреймворке (jquery например) реализуется в три десятка строчек кода.
А писать такие решения без фреймворков вообще — имхо глупость.
«зааяксивание» форм (любых форм и без потери функциональности) на любом аякс-фреймворке (jquery например) реализуется в три десятка строчек кода.
А писать такие решения без фреймворков вообще — имхо глупость.
Terion, главной идей не было просто «зааяксить форму». Идея была в том, чтобы в runtime режиме переделать форму так, чтобы обычное Web-приложение ходило по Ajax, т.е. вы берете независимое Web-приложение, вставляете его в портальную страницу так, чтобы оно работало как и прежде (полностью сохранялась прежняя функциональность). Это нужно, чтобы из обычного Web-приложения получился порлет. Зачем тут нужен Ajax? -Чтобы submit этого ставленого в портальную страницу Web-приложения не вызвал перезагрузку всей портальной страницы. Это можно только сделать через Ajax и фреймы.
Это делается путем блокировки сабмита (возвратом false в конце обработчика onSubmit), onSubmit упаковки данных формы в строку и отправки ее аяксом по атрибуту action формы методом, указанным в атрибуте method формы.
А дальше слушаем ответ и обрабатываем его как угодно.
Всё. И не нужны никакие фреймы.
Одна функция (или класс) на несколько десятков строк, провешенный на $(form).live() (для jQuery). и не нужно городить никаких огородов.
А дальше слушаем ответ и обрабатываем его как угодно.
Всё. И не нужны никакие фреймы.
Одна функция (или класс) на несколько десятков строк, провешенный на $(form).live() (для jQuery). и не нужно городить никаких огородов.
Terion, Вы правы, реализация Ajax Submit это только часть функционала ajax4all. Наверное 10%. Я из принципа только что посчитал все необходимые строчки: ajax4all_core.js (89 строчек или 4178 с форматированием без комментариев) и ajax4all_submit.js (65 строчек или 2643 с форматированием без комментариев). Думая, соизмеримо, если бы я писал это на jQuery. В самом начале, я сделал реализацию по верх Bindows и чуть не начал ваять версию под Dojo. Мода такая переменчивая… Главное я не хотел зависеть от какого-то фреймворка и как у любого решения тут свои плюсы и минусы. Представляете если бы Вы были фанатом Dojo?!!! Стали бы вы пользоваться библиотекой написанной под jQuery… Тоже самое касается ExtJS. Может быть я сделаю позже или при поддержке (например, при помощи гранда или спонсора) или если найду инвестора.
Да я jQuery привожу лишь в качестве примера.
Какой фреймворк — не важно.
Просто писанина велосипедов — занятие неблагодарное и ненужное.
Есть редкие случаи, когда действительно нужно писать голым кодом (будь то яваскрипт или пхп), но подобного рода приложение — явно не тот случай.
Какой фреймворк — не важно.
Просто писанина велосипедов — занятие неблагодарное и ненужное.
Есть редкие случаи, когда действительно нужно писать голым кодом (будь то яваскрипт или пхп), но подобного рода приложение — явно не тот случай.
«Представляете если бы Вы были фанатом Dojo?!!! Стали бы вы пользоваться библиотекой написанной под jQuery»
— ничто не мешает их совмещать, кстати. Джейквери легко изолируется и они не будут друг другу мешать.
А работать с голым яваскриптом фанату доджо — не думаю, что легче и лучше)
— ничто не мешает их совмещать, кстати. Джейквери легко изолируется и они не будут друг другу мешать.
А работать с голым яваскриптом фанату доджо — не думаю, что легче и лучше)
Да, единственный случай, когда действительно не обойтись без фреймов — это когда аплоадятся файлы.
Но опять же ничто не мешает добавить несколько строк для обработки этого случая.
И да, у вас там написан ровно этот же метод, я «прицепился» к тому, что вы расписали это как что-то страшно сложное, на что у вас ушло несколько месяцев поисков решений, хотя искать тут абсолютно нечего, совершенно тривиальная задача.
А раз вам она далась с таким трудом — то говорить о качестве конечного продукта не приходится. Да и сама по себе концепция, как я уже выше писал, мягко говоря, «не идеальная».
Но опять же ничто не мешает добавить несколько строк для обработки этого случая.
И да, у вас там написан ровно этот же метод, я «прицепился» к тому, что вы расписали это как что-то страшно сложное, на что у вас ушло несколько месяцев поисков решений, хотя искать тут абсолютно нечего, совершенно тривиальная задача.
А раз вам она далась с таким трудом — то говорить о качестве конечного продукта не приходится. Да и сама по себе концепция, как я уже выше писал, мягко говоря, «не идеальная».
Sign up to leave a comment.
Стартап: Технология Ajax Portal — на пути к энтерпрайз порталам нового поколения