Я к этой штуке отношения не имею, меня только алгоритм интересовал, поэтому описание критериев и колноки «Расчет» мне было достаточно. Конечно же, интересно, как у Гугла реализованно, лень мешает глянуть, может у них там через js как раз. Все равно интересен именно алгоритм, а не реализация.
Никаких проблем! RIA приложение это не блог или сайт строительной компании. Конечно тут могут быть разные варианты, но, к примеру, кому из разработчиков gmailа приходила в голову мысль о его проблемах с SEO?
Если мы говорим про RIA приложения, т.е. про приложения достаточно нагруженные клиентской логикой, красивым UI и т.д. то да, я действительно считаю, что передать структуру, допустим «акции», обновляющиеся раз в минуту в виде:
{
{
имя: «MSFT»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
},
{
имя: «GOOG»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
}
}
гораздо мение накладно, чем каждый раз генерить полную страничку с этой информацией. И чем сложнее приложение (отображение истории, динамики и т.д.) тем больше будет заметна эта разница. Хотя, я может быть вас не совсем понял, тогда извиняюсь.
Под стандартизацией я подразумевал возможность проецировать архитектуру такого приложения на существующие идеологии веб-сервисов или REST, к примеру — и как итог получить в распоряжение весь инструментарий доступный для них: фреймворки, стандарты и т.д. Прошу прощения, не успеваю раскрыть мысль, нужно бежать.
У вас и у автора немного разные понятия клиента. Для автора клиентом является приложение, способоное работать с конкретной задачей, браузер выступает в качестве движка рендера пользовательского интерфеса, движка для скриптового языка и реализацией чистого http(s), а у вас это универсальный клиент для отображения html+css+js… Подход описанный в статье ни в коем случае не претендует на универсальность! Это нишевый подход для построения RIA приложений, использующий стандарты.
Пожалуйста, не привязывайтесь только к HTML и иже. Я как-то говорил и повторю, что для меня главным для RIA приложения считается протокол, а не его реализация в конкретном клиенте. В вашем примере с IM можно красиво провести аналогию: есть ОДИН протокол и много клиентов, какие-то онлайновые, скажем, написаные на флеше, какие-то написаны только под Линукс, что-то под Мак и т.д.
>> Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера).
В виде статики, во-первых. Во-вторых приложение очень легко и просто сделать локальным в полном смысле этого слова с помощью MozillaPrizm к примеру. В-третьих, при открытости протокола достаточно просто писать любые клиенты, какие вам угодно, хоть на Бейсике под ДотНет, хоть на ObjC под IPhone.
— скорость загрузки приложения:
будет меньше (хуже), чем у классического приложения, за счет того, что этап «запуска» такого приложения, по сути, этап полной загрузки исходного кода клиента. Но в дальнейшем таких «тяжелых» запросов не будет, а вот при классическом подходе очень даже возможно. В двух словах, график загрузки клиента сначала взлетит «в небо», по сравнению с классическим, но потом трафик будет идти только за счет относительно небольших ajax запросов, а в классике траф будет расти постоянно лесенкой, при каждой загрузке страницы. Это плюс любого ajax приложения вообще, с самого начала раскрутки ajax в инете графики были известны. [Плюшки: задачи проще делить физически между программистами/командами/фирмами и т.д., можно сделать несколько клиентов, можно опубликовать апи и т.д.]
— время отклика: что быстрее серверу, сформировать и выплюнуть html-страничку, (обычно это куча инклюдов или их аналогов, дергание кучи кода и т.д.) или же отдать компактный ответ в JSON (Ну или на худой конец в XML)? Подумайте сами. Плюс подхода — стандартизация, из клиента мы может обращаться к веб-сервису, для примера. [Разработка: проще построить стандартизированное монолитное приложение, проще сопровождать, можно обсудить подробнее]
— уровень загруженности сервера: прямо зависит от двух прошлых пунктов, сами сделайте вывод, что больше грузит сервер. (Если у вас не новостной проект и вы не отдаете статику) [Разработка: проще рулить нагрузкой, ваш клиент может обращатся к 3-4 независимым сервисам, допустим]
— скорость разработки сайта: зависит от команды и от ее опыта, а так же от наличия подходящего инструментария в виде фреймворков и т.д. Тут все очень субьективно.
Простите, на работе нет времени на более подробный ответ.
Состарюсь вот, соберу вокруг себя внуков и буду восторженно рассказывать, как пол года копил на комп и поиграл в кризис на максимальных настройках с 2 ФПС. А они буду так сочувственно кивать и говорить «Во деда динозавр, на таком дохлом железе во что-то еще и играть умудрялся» А я такой «Эх молодеж, вам 4Д подавай, а игры ваши все пустышки, толи дело в мои времена. Дааа игры уже не те :)»
Такой шкаф можно изготовить в домашних условиях:
1. Берем обычный шкаф из Икеи.
2. Пол часа распиливаем его пополам, но не до конца.
3. Следующие пол часа выдергиваем откуда-нибудь резинки.
4. Пятнадцать минут склеиваем.
5. Пару часов оборачиваем книги в картон.
6. Тестим, фотографируем в девушкой на переднем плане :)
Что тут актуального? Если в e.u.l.a какой-нибудь игры будет указана строчка: «Нажимая далее вы передаете всю свою недвижимость в дар производилю этого ПО» и вы нажмете далее, не прочитав — производитель софта получит вашу дачу? Конечно же нет, любой договор может быть признан незаконным целиком или частично.
Что-то я злой стал, комикс не понравился :(
<Теория-заговора>Ну что вы, они им ИИ подсобили, пару миллионов на рекламу, а там глядишь, народ подсядет — можно будет базы сливать :)</Теория-заговора>
А если серьезно, очень интересно, что там эта система хваленая сможет сделать такого, особенно с русским менталитетом загадочным. Вот по своему опыту говорю, копил деньги на апгрейд сколько времени, а потом раз, что-то в голову ударило, и купил ноут, о чем не жалею. Все буквально за неделю произошло. И как вот такое можно предсказать? А ради функции расширенной напоминалки о событиях стоит ли тратить такие деньги? Хотя интеграция с платежными системами очень интересная фишка для пима, но как-то стремно что-ли доверять свою кредитку ИИ.
Ничего страшного, вы были правы со своей точки зрения — для серьезного учебника содержание статьи оценивать можно с точки зрения профанации идеи. Однако, если статью прочитает менеджер, к примеру, ему суть будет так же понятна, как и программисту, пускай последний будет кривить лицо на некоторые мои пассажи.
Ссылок к сожанию не дам, слышал 2 варианта от разных людей. Я не переводчик, поэтому не знаю, first class object лучше переводить дословно или нет :) Пример с анонимными функциями добавлю чуть попозже :)
Как я понимаю, вы не пользуетесь фреймворками навроде extjs? Для своего приложения мы в самом начале заготовили обычные сверстаные макеты всех типовых элементов: окошек, менюшек и т.д, разметили структуру главной страницы и «захардкодили» логику построения всего этого добра в js. К примеру, главное меню отрисовывет класс MainMenu, а вот уже доступные действия подружаются в виде json-списков с сервера.Т.е, по сути, весь html помещен в обертки из js — поэтому клиент вообще не зависит от сервера. Если вы не планируете переход на другие виды клиентов, к примеру флеш или нативные десктопные клиенты, вам может и не понадобится такое отделение.
Быстро погуглил, самое наглядное что нашел по теме, вот: Проверка сложности пароля
{
{
имя: «MSFT»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
},
{
имя: «GOOG»,
стоимость_в_уе:0,
страшный_параметр1:bla,
страшный_параметр2:bla-bla,
}
}
гораздо мение накладно, чем каждый раз генерить полную страничку с этой информацией. И чем сложнее приложение (отображение истории, динамики и т.д.) тем больше будет заметна эта разница. Хотя, я может быть вас не совсем понял, тогда извиняюсь.
Под стандартизацией я подразумевал возможность проецировать архитектуру такого приложения на существующие идеологии веб-сервисов или REST, к примеру — и как итог получить в распоряжение весь инструментарий доступный для них: фреймворки, стандарты и т.д. Прошу прощения, не успеваю раскрыть мысль, нужно бежать.
Пожалуйста, не привязывайтесь только к HTML и иже. Я как-то говорил и повторю, что для меня главным для RIA приложения считается протокол, а не его реализация в конкретном клиенте. В вашем примере с IM можно красиво провести аналогию: есть ОДИН протокол и много клиентов, какие-то онлайновые, скажем, написаные на флеше, какие-то написаны только под Линукс, что-то под Мак и т.д.
>> Так, что как вы не бейтесь, все равно, Отображение генерится на сервере(HTML, CSS, JS, медия все берется с сервера).
В виде статики, во-первых. Во-вторых приложение очень легко и просто сделать локальным в полном смысле этого слова с помощью MozillaPrizm к примеру. В-третьих, при открытости протокола достаточно просто писать любые клиенты, какие вам угодно, хоть на Бейсике под ДотНет, хоть на ObjC под IPhone.
— скорость загрузки приложения:
будет меньше (хуже), чем у классического приложения, за счет того, что этап «запуска» такого приложения, по сути, этап полной загрузки исходного кода клиента. Но в дальнейшем таких «тяжелых» запросов не будет, а вот при классическом подходе очень даже возможно. В двух словах, график загрузки клиента сначала взлетит «в небо», по сравнению с классическим, но потом трафик будет идти только за счет относительно небольших ajax запросов, а в классике траф будет расти постоянно лесенкой, при каждой загрузке страницы. Это плюс любого ajax приложения вообще, с самого начала раскрутки ajax в инете графики были известны. [Плюшки: задачи проще делить физически между программистами/командами/фирмами и т.д., можно сделать несколько клиентов, можно опубликовать апи и т.д.]
— время отклика: что быстрее серверу, сформировать и выплюнуть html-страничку, (обычно это куча инклюдов или их аналогов, дергание кучи кода и т.д.) или же отдать компактный ответ в JSON (Ну или на худой конец в XML)? Подумайте сами. Плюс подхода — стандартизация, из клиента мы может обращаться к веб-сервису, для примера. [Разработка: проще построить стандартизированное монолитное приложение, проще сопровождать, можно обсудить подробнее]
— уровень загруженности сервера: прямо зависит от двух прошлых пунктов, сами сделайте вывод, что больше грузит сервер. (Если у вас не новостной проект и вы не отдаете статику) [Разработка: проще рулить нагрузкой, ваш клиент может обращатся к 3-4 независимым сервисам, допустим]
— скорость разработки сайта: зависит от команды и от ее опыта, а так же от наличия подходящего инструментария в виде фреймворков и т.д. Тут все очень субьективно.
Простите, на работе нет времени на более подробный ответ.
1. Берем обычный шкаф из Икеи.
2. Пол часа распиливаем его пополам, но не до конца.
3. Следующие пол часа выдергиваем откуда-нибудь резинки.
4. Пятнадцать минут склеиваем.
5. Пару часов оборачиваем книги в картон.
6. Тестим, фотографируем в девушкой на переднем плане :)
Что-то я злой стал, комикс не понравился :(
А если серьезно, очень интересно, что там эта система хваленая сможет сделать такого, особенно с русским менталитетом загадочным. Вот по своему опыту говорю, копил деньги на апгрейд сколько времени, а потом раз, что-то в голову ударило, и купил ноут, о чем не жалею. Все буквально за неделю произошло. И как вот такое можно предсказать? А ради функции расширенной напоминалки о событиях стоит ли тратить такие деньги? Хотя интеграция с платежными системами очень интересная фишка для пима, но как-то стремно что-ли доверять свою кредитку ИИ.
Просто так ;)
> Функция, как объект первого рода
поправил, хотя слышал два варианта употребления
> Кстати, не показано, что функции можно также и возвращать из функций
А пример замыканий?