Теперь с GWT 2, каковы преимущества перед калиткой и аналогично?

Я заставил его работать, но решение немного сложно, поэтому терпите меня.

, Что происходит

, Как это, Internet Explorer дает более низкий уровень доверия страницам IFRAME (IE называет это "стороннее" содержание). Если страница в IFRAME не имеет Политики конфиденциальности, ее куки заблокированы (который обозначается значком глаза в строке состояния, когда Вы нажимаете на него, это показывает Вам список заблокированных URL).

the evil eye
(источник: piskvor.org )

В этом случае, когда куки заблокированы, идентификатор сессии не отправляется, и целевой сценарий бросает 'сессию, не найденную' ошибка.

(я попытался установить идентификатор сессии в форму и загрузить его из переменных POST. Это работало бы , но по политическим причинам я не мог сделать этого.)

возможно сделать страницу в IFRAME более доверяемой: , если внутренняя страница отправляет заголовок P3P с политикой конфиденциальности, которая приемлема для IE, куки будут приняты .

, Как решить, это

Создает p3p политику

А, который хорошая начальная точка учебное руководство по W3C. Я прошел его, загрузил Редактор Политики конфиденциальности IBM , и там я создал представление политики конфиденциальности и дал ей имя для ссылки на нее (здесь, это было policy1).

ПРИМЕЧАНИЕ : в этой точке на самом деле необходимо узнать, имеет ли сайт политику конфиденциальности, и в противном случае создайте его - собирает ли это пользовательские данные, какой данные, что это делает с ним, у кого есть доступ к нему и т.д. Необходимо найти, что эта информация и думает об этом. Просто удар вместе несколько тегов не сократят его. Этот шаг не может быть сделан просто в программном обеспечении и может быть очень политическим (например, "мы должны продать нашу статистику щелчка?").

(например, "сайт управляется ACME Ltd., он использует анонимные идентификаторы на сессию для своей операции, собирает пользовательские данные, только если явно разрешенный и только в следующих целях, данные хранятся только настолько же долго по мере необходимости, только наша компания имеет доступ к нему, и т.д. и т.д. ").

(При редактировании с этим инструментом, возможно просмотреть ошибки/пропуск в политике. Также очень полезный вкладка "HTML Policy": в нижней части это имеет "Оценку политики" - быстрая проверка, если политика будет заблокирована настройками по умолчанию IE)

, Редактор экспортирует в .p3p файл, который является представлением XML вышеупомянутой политики. Кроме того, это может экспортировать "компактную версию" этой политики.

Ссылка на политику

Тогда Ссылочный файл политики (http://example.com/w3c/p3p.xml) был необходим (индекс политик конфиденциальности использование сайта):


  
    
      /
      
    
  

шоу весь URIs, который будет использовать эту политику (в моем случае, целом сайте). Файл политики, который я экспортировал от Редактора, был загружен на http://example.com/w3c/example-com.p3p

, Отправляют компактный заголовок с ответами

, я установил веб-сервер по example.com для отправки компактного заголовка с ответами, как это:

HTTP/1.1 200 OK 
P3P: policyref="/w3c/p3p.xml", CP="IDC DSP COR IVAi IVDi OUR TST"
// ... other headers and content

policyref относительный URI к Ссылочному файлу политики (который в свою очередь ссылается на политики конфиденциальности), CP компактное представление политики. Примечание, что комбинация заголовков P3P в примере не может быть применимой на Вашем определенном веб-сайте; Ваши заголовки P3P ДОЛЖНЫ правдиво представить Вашу собственную политику конфиденциальности!

Прибыль!

В этой конфигурации, Дурной глаз не появляется, cookie сохраняются даже в IFRAME и работах приложения.

Редактирование: Что НЕ сделать, если Вам не нравится защищать от судебных процессов

, Несколько человек предложили "просто удар некоторые теги в Ваш заголовок P3P, пока Дурной глаз не сдается".

теги не являются только набором битов, они имеют значения реального мира , и их использование дает Вам обязанности по реальному миру !

, Например, притворяясь то, что Вы никогда не собираете пользовательские данные, могло бы сделать браузер счастливым, но если Вы на самом деле собираете пользовательские данные, P3P конфликтует с действительностью. Простой и простой, Вы целеустремленно лжете своим пользователям , и это могло бы быть преступным поведением в некоторых странах. Как в, "попадают в тюрьму, не собирают 200$".

Несколько примеров ( см. p3pwriter для полного набора тегов ):

  • NOI: "Веб-сайт не делает собранных определенных данных". (как только существует какая-либо настройка, вход в систему или какой-либо сбор данных (***** Аналитика, кто-либо?), Вы должны подтверждать его в своем P3P)
  • STP: информация сохраняется для встречи формулируемой цели. Это запрашивает информацию, которая будет отброшена в самое раннее возможное время. Сайты ДОЛЖНЫ иметь политику хранения, которая устанавливает таблицу времени разрушения. Политика хранения ДОЛЖНА быть включена в или связана от человекочитаемой политики конфиденциальности сайта". (таким образом, если Вы отправляете STP, но не имеете политики хранения, Вы можете совершить мошенничество. Насколько прохладный это? Нисколько.)

я не адвокат, но я не готов обратиться в суд, чтобы видеть, ли заголовок P3P действительно юридически обязателен или если можно обещать пользователям что-либо без на самом деле согласного для удостаивания обещаний.

8
задан Jonas 18 June 2011 в 10:12
поделиться

7 ответов

На мой взгляд, самое большое преимущество GWT - это возможность работать с одним языком программирования - Java, со всеми его достоинствами. оно приносит.

Вместе с CSS они образуют мощную пару.


Другими словами, вы можете в основном забыть Javascript и HTML.

Является ли это преимуществом или нет, во многом зависит от ваших навыков и требований. Мы'

2
ответ дан 5 December 2019 в 05:03
поделиться

Несколько нечестно сравнивать GWT с калиткой (или аналогичным образом), поскольку они действительно происходят из двух разных лагерей. Первый представляет собой структуру для создания интерфейсных приложений JavaScript, а второй - классическую структуру веб-приложений Java.

Таким образом, приведенные ниже пункты не столько, как GWT и калитка, сколько общий список, который был составлен, когда мы решили использовать GWT для расширенного веб-приложения JavaScript / AJAX:

  • скрывает недостатки поддержки JavaScript и кроссбраузерности, позволяя разрабатывать на Java и автоматически компилировать в специфичный для браузера вариант JavaScript
  • развивающаяся структура с версиями 1.6+ и будущими версиями 2.0: (шина событий, обработчики событий, архитектура графического интерфейса пользователя с шаблоном MVP, оптимизация компилятора и т. Д.).
3
ответ дан 5 December 2019 в 05:03
поделиться

Я могу придумать несколько причин, по которым GWT лучший выбор, чем Wicket, для типичных бизнес-приложений:

  1. GWT от Google. Это может быть несправедливо, но наличие у инструмента крупной и уважаемой компании-разработчика программного обеспечения - это огромное преимущество (безопаснее делать ставки на него, больше книг и онлайн-ресурсов, больше сторонней поддержки, лучше поддержка IDE,. ..).
  2. Серверно-ориентированные веб-фреймворки, такие как Wicket, устарели. Современные веб-браузеры очень мощны и становятся все более эффективными, поэтому современная веб-платформа должна помочь вам воспользоваться этим.
  3. Кодирование непосредственно в HTML и Javascript никогда не может быть таким продуктивным, как кодирование на Java (по крайней мере, из моего опыта ). Также, есть более эффективные инструменты для Java-кода (отладчики, статический анализ, модульное тестирование, покрытие кода и т. д.).
0
ответ дан 5 December 2019 в 05:03
поделиться

Гений GWT состоит в том, что вы работаете исключительно с java. Они отлично поработали с RPC, сделав его почти прозрачным для программиста. Часто вам кажется, что кодирование больше похоже на настольное приложение, а не на приложение с действительно определенной клиентской и серверной стороной.

0
ответ дан 5 December 2019 в 05:03
поделиться

The advantages are, basically, that GWT is a tool to build javascript-based client, thus, it's best suited if you want a javascript-based client.

Wicket centers on the server, and while it makes it quite easy to embed javascript into stateless pages, server-side state handling is the more natural approach.

One must note that the architectures are very different.

With GWT, your architecture turns into client-server, a thick client on the browser, making calls to 'procedures' (services) to the server, sending and receiving data.

With Wicket (and other server-side-centric component frameworks, like JSF and Tapestry), the architecture is a more 'traditional' 3-layer one, and what is sent and received are pages or fragments of the pages, not pure data.

While you can certainly blend both to adapt to the other architecture, it simply wouldn't be very natural.

People tend to focus on 'which is easier to use' (which is completely subjective, depending on your background), or 'which is more beautiful and has more components', but one should not underestimate the architectural difference, which affects the approach you have to take to handle aspects like security and scalability.

17
ответ дан 5 December 2019 в 05:03
поделиться

Последние несколько месяцев я участвовал в проекте на базе GWT. Я был, будучи частью команды разработчиков Wicket в течение многих лет, с нетерпением ждал перемен, и многого ожидал от GWT (который всегда был для меня еще одним замечательным Java-фреймворком).

Честно говоря, я разочарован, когда дело доходит до работы с GWT. Я чувствую - на самом деле, вся моя команда - что производительность получила большой успех. Теоретически GWT великолепен. Но когда вы учитываете причуды и ограничения фреймворка, посредственные сообщения об ошибках (особенно когда речь идет об ошибках сериализации), длительное время компиляции (где-то от 3 до 10 минут, а наш проект еще даже не настолько велик), тот факт, что когда все сказано и сделано, то это когда все сказано и сделано, Вам все равно нужно протестировать все браузеры и найти обходные пути, тот факт, что он производит огромную начальную загрузку (почти мегабайт, который мы урезаем постепенно, но с большими усилиями) и т.д., и т.п., мне кажется, что с Wicket работать намного проще и быстрее.

Я не ненавижу работать с GWT. Он все еще намного лучше, чем большинство Java-фреймворков. Просто я ожидал от работы с ним гораздо большего; я даже ожидал, что он будет, возможно, лучше, чем Wicket. Но в конце концов, это просто не имхо. Надеюсь, GWT 2.0 многое улучшит, и, надеюсь, некоторые причуды плагина Eclipse тоже будут исправлены в ближайшее время.

10
ответ дан 5 December 2019 в 05:03
поделиться

Одним из преимуществ Wicket перед GWT является то, что Wicket может справиться с ситуацией, когда вы хотите предоставить запасной вариант для клиентов, у которых не включен Javascript. GWT полностью поддерживает Javascript, Wicket позволяет изящно деградировать.

3
ответ дан 5 December 2019 в 05:03
поделиться
Другие вопросы по тегам:

Похожие вопросы: