Доступ к clipboard/поддержку storage в опере можно сделать с использованием flash. Мне кажется, это несколько проще, чем шаманство с плагинами и userjs.
Асинхронные операции webkit'а неудобны для разработки. Простая последовательность из нескольких прочитать/записать превращается в неудобочитаемое спагетти. Проще использовать флэш.
1. Использование локального хранилища позволяет организовать обмен данным между окнами браузера (причём не важно, как эти окна были открыты и что с ними происходило)
2. Можно сохранять данные пользователя даже в offline
Для начинающего программиста тех времён весьма. Кроме того, книга содержала листинги на нескольких языках программирования для разных машин (PC, Ямаха). Это делало её настоящим кладезем информации для умеющих (или пытающихся) читать между строк, делать логические выводы, а главное желающих учиться.
Открытый код позволяет тем, кто его использует, найти причину непонятного/неправильного поведения продукта или прояснить какие-то моменты, недостаточно полно освещённые в документации. Т.е. мне, как разработчику, иметь исходники сторонних библиотек крайне полезно.
Да, документирование краеугольный камень. В случае сторонней стандартизированной библиотеки эта работа уже проделана. В случае популярной библиотеки про неё даже книги написаны.
Проблемы лицензирования относятся к самописному коду в той же мере, что и к публичному права на разработанный код могли уйти к заказчику. Изобретать индивидуальный велосипед для каждого заказчика? Дороговато. Завышать стоимость прочих работ, чтобы скрыть от заказчика наработки, которые планируется использовать в других проектах?
"Отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода" гарантий не даёт, но вероятность заметно повышает. Помимо устранения собственных ошибок библиотеки, обычно учитывается масса чужих.
Если разработчики бросают серьёзный проект, и тот умирает либо появляется альтернативная библиотека, либо проект был несерьёзным и вы изначально сделали неверный выбор.
Кстати, о сотрудниках (в скобках замечу, что найти технического писателя обычно сложнее, чем библиотеку). Использование сторонних библиотек выгодно не только заказчику/работодателю, но и самому разработчику. Что лучше пять лет разрабатывать очередной велосипед и, уволившись, осознать, что твои знания о com.geocities.world.wide.selpro.podsobka.reportgen никому не нужны, или быть уверенным в том, что со своими знаниями и опытом сможешь найти работу без каких-либо проблем?
После ухода 1-2 сотрудников, в головах которых содержатся основные знания об этом самописном коде ваши колёса превратятся в тыквы. Возможно, заодно с проектами.
Оформление и документирование самописного кода на уровне, достаточном для безболезненной потери его автора выливается в такую копеечку, что умеющие считать люди десять раз подумают и погуглят, прежде чем решатся на самостоятельную реализацию колеса.
Стандартные библиотеки отлаживаются и используются большим числом людей, чем вы можете надеяться со своими собственными разработками.
А если кому-то лень разбираться с чужим колесом так он и своё сделает коряво.
Подразумеваю ровно то, что написал. Зачем jsp знать о том, что она работает в среде портлет-контейнера, если в этом нет особой необходимости? Её дело обеспечивать представление. Подготовили данные, передали и пусть себе рисует.
Во-первых, привязка к портлету уменьшит возможность повторного использования этой jsp. В одном из следующих постов Вы наверняка нарисуете jsp, которая будет показывать информацию о найденном сотруднике. Вернёмся к нашей предыдущей беседе и вспомним один из недостатков портлетной технологии проблему ссылок. Если в проекте когда-нибудь понадобится показывать информацию о сотруднике по простой короткой ссылке (/employee?12345), то, имея jsp, которая не привязана к портлетному окружению, мы можем использовать её повторно, просто установив нужные атрибуты из сервлета.
Во-вторых, чем больше мест, в которых методы окружения вызываются непосредственно тем больше сложностей возникает, когда надо изменить поведение системы или написать workaround для чужого бага (ситуация, конечно, редкая, но, увы, не невероятная).
Да, есть конкретные портлеты и, вероятно, целые проекты, в которых заботиться о подобных вещах нет смысла. Но говорить в обучающей статье (утрирую) "не понимаю, нафига такие сложности" на мой взгляд, неправильно.
Что касается jstl, то код с ним выглядит аккуратнее, чем каша из скриптлетов. Ещё такой код проще генерировать в xsl по какому-нибудь DSL, но это уже очень специфический плюс :)
ps: в листинге <%@page import="javax.portlet.*"%> два раза написан.
«Если внимательно почитать , то видно, что настройки рекомендуется передавать на jsp в виде атрибутов, хотя на самой jsp можно точно так же обратиться к настройкам через renderRequest.getPreferences().getValue(PREF_SHOWPERSONS,"") Зачем это делать - непонятно»
Возможно, для того, чтобы не рассказывать всей системе про javax.portlet.*, а во view настройки получать через обычный jstl ${showPersonsList}
Пользовательский контент шифровал ещё OneHalf в середине 90х (да и до него попадались экземпляры). Были и вирусы, которые просили денег, но их названия, увы, давно выветрились из головы.
Так что автор gpcode не гений, а человек, твёрдо знающий, что новое это хорошо забытое старое.
По результатам исследований, которые тысячи очень умных людей проводили последние несколько десятков лет, наиболее точным способом оценки является испытательный срок.
Мы для себя решили проблему межкомпонентного общения с помощью библиотеки OpenAjax (на самом деле, подойдёт любая библиотека, позволяющая подписываться на события и публиковать их). Компонент A публикует событие "ru.habrahabr.sergonavt.list.selected" и передаёт связанные с этим данные (например, id элемента списка, текст элемента списка). Компонент B подписан на это событие и создаёт закладки.
В любой момент мы можем добавить компонент C, который подпишется на это событие и будет, к примеру, подгружать раздел контекстной справки для выбранного элемента на коде и работоспособности A и B это никак не скажется.
Если мы уберём со страницы B и C A от этого работать не перестанет.
Если мы уберём со страницы A ну, B и C перестанут получать эти события. Если никаких других источников события нет и эти компоненты не реагируют аналогичным образом на другие события B и C перестанут открывать и подгружать (а вы думали, что в сказку попали? :) ). Но никаких ошибок javascript при этом тоже не будет.
Пример непонятен. Вы эти портлеты взяли из какого-то репозитория?
"Можно задать, к какой именно БД" вплоть до структуры? Вы можете сказать, что в этом проекте портлет должен доставать данные из таблицы users, а в этом из logins плюс сходить в LDAP? Или всё из того же users, но данные хранятся в CLOB-поле в виде vcard-xml. Сомневаюсь. В том-то и проблема, что невозможно разработать универсальный портлет и положить его в репозиторий всем на радость (или же вокруг него придётся дописывать своего кода больше, чем если делать свой собственный портлет). Потому я и говорю, что репозитории портлетов миф.
Возвращаясь к примеру в данном случае сложно рассуждать о полезности портлетов, не имея данных об их повторном использовании на других страницах. Пока видно только ограничение видимости отдельных частей одной страницы, что можно было бы настроить и как-нибудь ещё.
Кстати, какой из портлетов здесь отвечает за формирование title и keywords страницы?
Основная проблема портлетной технологии в том, что она рассматривает страницу как набор _независимых_ блоков, что, как правило, не так. Если есть список где-то на странице есть фильтр(ы). Если есть просмотр где-то наверняка есть комментирование (кругом web 2.0, UGC). Да, в 286 сделали обмен сообщениями но это всё равно механизм для взаимодействия слабосвязанных объектов, да ещё и порождается по итогам ActionRequest. Представьте себе, что на странице есть список документов и пара фильтров. Как при простом заходе на страницу Вы сможете отфильтровать список какими-то дефолтным способом?
По сути дела, страница из портлетов подобна набору фреймов со всеми проблемами фреймовой структуры. Отдать пользователю постоянную ссылку на страницу практически невозможно параметры либо легли в сессию/RenderRequest после предыдущего post-запроса и редиректа, либо url страшен, как смертный грех. Один из вопросов, который кочевал от заказчика к заказчику "нельзя ли сделать url попроще?"
По поводу моих слов о надуманности примера с калькулятором и репозиторим портлетов. Скажите, Вы действительно считаете, что на сайте необходим блок с погодой, JNDI-браузер или непонятная замена браузерных букмарков/любого сервиса букмарков? Вас не настораживал тот факт, что мысль сторонних разработчиков не пошла дальше этих игрушечных компонент? Никто почему-то не написал форум, который мистическим образом интегрируется с моими пользователями и классификаторами. Никто почему-то не написал облако тегов, которое интегрируется с моими типами объектов в моей БД. Никто даже не написал простейшего списка, который показывал бы объекты в соответствии с системой прав и состояниями docflow/workflow/someshitflow. Репозитории 3rd-party портлетов это миф, наполненный калькуляторами и интеграцией с Flicrk'ами.
"Чувствуете какой кайф? Портлет, считай, как маленькое веб-приложение, которое можно поместить на страничку портала и настроить"
Не вводите людей в заблуждение надуманным примером с калькулятором, пожалуйста вместо слова "кайф" должно быть "геморрой". Портлетная технология создаёт множество проблем и ни одной (кроме _одноразовой_ настройки структуры страницы) не решает (или решает в стиле "сферического коня", налагая дополнительные ограничения).
Вы, наверное, никогда не работали с PDF как программист (ну или только формировали его). Если посмотреть на pdf, как на источник данных, то оно мало отличается от листа бумаги, на котором его напечатали.
Заранее жаль программистов microsoft. Ужасный формат. С учётом неудобств использования (кроме как в режиме "отправить на печать") любить его особо не за что.
1. Поддержка FF 1.5 была прекращена производителем 29 мая 2007 года. Если кто-то за год поленился обновить версию это исключительно его личные проблемы. Пользователи FF ведь считаются существами разумными?
2. Opera действительно ничего из этого не поддерживает. В зависимости от важности функционала, реализуемого через storage, можно либо не делать ничего, либо, например, реализовать хранение данных на сервере.
Ну и главное:
3. "Работает очень мало где" это, мягко говоря, преувеличение.
2. Можно сохранять данные пользователя даже в offline
Да, документирование краеугольный камень. В случае сторонней стандартизированной библиотеки эта работа уже проделана. В случае популярной библиотеки про неё даже книги написаны.
Проблемы лицензирования относятся к самописному коду в той же мере, что и к публичному права на разработанный код могли уйти к заказчику. Изобретать индивидуальный велосипед для каждого заказчика? Дороговато. Завышать стоимость прочих работ, чтобы скрыть от заказчика наработки, которые планируется использовать в других проектах?
"Отладка и использование кода большим числом людей не дает никаких гарантий отностельно качества кода" гарантий не даёт, но вероятность заметно повышает. Помимо устранения собственных ошибок библиотеки, обычно учитывается масса чужих.
Если разработчики бросают серьёзный проект, и тот умирает либо появляется альтернативная библиотека, либо проект был несерьёзным и вы изначально сделали неверный выбор.
Кстати, о сотрудниках (в скобках замечу, что найти технического писателя обычно сложнее, чем библиотеку). Использование сторонних библиотек выгодно не только заказчику/работодателю, но и самому разработчику. Что лучше пять лет разрабатывать очередной велосипед и, уволившись, осознать, что твои знания о com.geocities.world.wide.selpro.podsobka.reportgen никому не нужны, или быть уверенным в том, что со своими знаниями и опытом сможешь найти работу без каких-либо проблем?
Оформление и документирование самописного кода на уровне, достаточном для безболезненной потери его автора выливается в такую копеечку, что умеющие считать люди десять раз подумают и погуглят, прежде чем решатся на самостоятельную реализацию колеса.
Стандартные библиотеки отлаживаются и используются большим числом людей, чем вы можете надеяться со своими собственными разработками.
А если кому-то лень разбираться с чужим колесом так он и своё сделает коряво.
Во-первых, привязка к портлету уменьшит возможность повторного использования этой jsp. В одном из следующих постов Вы наверняка нарисуете jsp, которая будет показывать информацию о найденном сотруднике. Вернёмся к нашей предыдущей беседе и вспомним один из недостатков портлетной технологии проблему ссылок. Если в проекте когда-нибудь понадобится показывать информацию о сотруднике по простой короткой ссылке (/employee?12345), то, имея jsp, которая не привязана к портлетному окружению, мы можем использовать её повторно, просто установив нужные атрибуты из сервлета.
Во-вторых, чем больше мест, в которых методы окружения вызываются непосредственно тем больше сложностей возникает, когда надо изменить поведение системы или написать workaround для чужого бага (ситуация, конечно, редкая, но, увы, не невероятная).
Да, есть конкретные портлеты и, вероятно, целые проекты, в которых заботиться о подобных вещах нет смысла. Но говорить в обучающей статье (утрирую) "не понимаю, нафига такие сложности" на мой взгляд, неправильно.
Что касается jstl, то код с ним выглядит аккуратнее, чем каша из скриптлетов. Ещё такой код проще генерировать в xsl по какому-нибудь DSL, но это уже очень специфический плюс :)
ps: в листинге <%@page import="javax.portlet.*"%> два раза написан.
Возможно, для того, чтобы не рассказывать всей системе про javax.portlet.*, а во view настройки получать через обычный jstl ${showPersonsList}
Так что автор gpcode не гений, а человек, твёрдо знающий, что новое это хорошо забытое старое.
В любой момент мы можем добавить компонент C, который подпишется на это событие и будет, к примеру, подгружать раздел контекстной справки для выбранного элемента на коде и работоспособности A и B это никак не скажется.
Если мы уберём со страницы B и C A от этого работать не перестанет.
Если мы уберём со страницы A ну, B и C перестанут получать эти события. Если никаких других источников события нет и эти компоненты не реагируют аналогичным образом на другие события B и C перестанут открывать и подгружать (а вы думали, что в сказку попали? :) ). Но никаких ошибок javascript при этом тоже не будет.
"Можно задать, к какой именно БД" вплоть до структуры? Вы можете сказать, что в этом проекте портлет должен доставать данные из таблицы users, а в этом из logins плюс сходить в LDAP? Или всё из того же users, но данные хранятся в CLOB-поле в виде vcard-xml. Сомневаюсь. В том-то и проблема, что невозможно разработать универсальный портлет и положить его в репозиторий всем на радость (или же вокруг него придётся дописывать своего кода больше, чем если делать свой собственный портлет). Потому я и говорю, что репозитории портлетов миф.
Возвращаясь к примеру в данном случае сложно рассуждать о полезности портлетов, не имея данных об их повторном использовании на других страницах. Пока видно только ограничение видимости отдельных частей одной страницы, что можно было бы настроить и как-нибудь ещё.
Кстати, какой из портлетов здесь отвечает за формирование title и keywords страницы?
По сути дела, страница из портлетов подобна набору фреймов со всеми проблемами фреймовой структуры. Отдать пользователю постоянную ссылку на страницу практически невозможно параметры либо легли в сессию/RenderRequest после предыдущего post-запроса и редиректа, либо url страшен, как смертный грех. Один из вопросов, который кочевал от заказчика к заказчику "нельзя ли сделать url попроще?"
По поводу моих слов о надуманности примера с калькулятором и репозиторим портлетов. Скажите, Вы действительно считаете, что на сайте необходим блок с погодой, JNDI-браузер или непонятная замена браузерных букмарков/любого сервиса букмарков? Вас не настораживал тот факт, что мысль сторонних разработчиков не пошла дальше этих игрушечных компонент? Никто почему-то не написал форум, который мистическим образом интегрируется с моими пользователями и классификаторами. Никто почему-то не написал облако тегов, которое интегрируется с моими типами объектов в моей БД. Никто даже не написал простейшего списка, который показывал бы объекты в соответствии с системой прав и состояниями docflow/workflow/someshitflow. Репозитории 3rd-party портлетов это миф, наполненный калькуляторами и интеграцией с Flicrk'ами.
Не вводите людей в заблуждение надуманным примером с калькулятором, пожалуйста вместо слова "кайф" должно быть "геморрой". Портлетная технология создаёт множество проблем и ни одной (кроме _одноразовой_ настройки структуры страницы) не решает (или решает в стиле "сферического коня", налагая дополнительные ограничения).
Заранее жаль программистов microsoft. Ужасный формат. С учётом неудобств использования (кроме как в режиме "отправить на печать") любить его особо не за что.
2. Opera действительно ничего из этого не поддерживает. В зависимости от важности функционала, реализуемого через storage, можно либо не делать ничего, либо, например, реализовать хранение данных на сервере.
Ну и главное:
3. "Работает очень мало где" это, мягко говоря, преувеличение.