Несколько страниц в GWT с понятными для человека URL-адресами

Я играю с проектом GWT / GAE, который будет иметь три разные «страницы», хотя на самом деле это не страницы в смысле GWT. Верхние представления (по одному для каждой страницы) будут иметь совершенно разные макеты, но некоторые из виджетов будут общими.

Одна из страниц - это главная страница, которая загружается по URL-адресу по умолчанию (http://www.site.com), но двум другим нужна дополнительная информация об URL-адресе, чтобы различать тип страницы. Им также нужен параметр имени (например, http://www.site.com/project/project-name. Я знаю как минимум два решения этой проблемы.

  1. Используйте механизм истории GWT и позвольте типу страницы и параметрам (например, имени проекта) быть частью токена истории.
  2. Используйте сервлеты с шаблонами сопоставления URL-адресов (например, / project / *)

Первый выбор сначала может показаться очевидным, но у него есть несколько недостатков. Во-первых, пользователь должен легко запоминать и вводить URL-адрес проекта. Трудно создать удобный для человека URL-адрес с токенами истории. Во-вторых, я использую gwt-presenter, и этот подход будет означать, что нам нужно поддерживать подместы в одном токене, чего я бы предпочел избежать. В-третьих, пользователь обычно остается на одной странице, поэтому имеет больше смысла, что информация о странице является частью «статического» URL-адреса.

Использование сервлетов решает все эти проблемы, но также создает другие.

Итак, мои первые вопросы: какое здесь лучшее решение?

Если бы я выбрал решение сервлета, появятся новые вопросы.

  1. Возможно, имеет смысл разделить приложение GWT на три отдельных модуля, каждый с точкой входа. Каждый сервлет, отображаемый на определенную страницу, затем просто пересылает запрос модулю GWT, который обрабатывает эту страницу. Поскольку пользователь обычно остается на одной странице, браузеру нужно только загрузить js для этой страницы. Судя по тому, что я читал, это решение не рекомендуется.

Я также мог бы придерживаться одного модуля, но тогда GWT нужно выяснить, какую страницу он должен отображать. Он может либо запросить сервер, либо проанализировать сам URL.

  1. Если я придерживаюсь одного модуля GWT, мне нужно хранить информацию о странице на стороне сервера. Естественно, я думал о сеансах, но не уверен, стоит ли смешивать информацию о странице с данными пользователя. Сеанс обычно находится между входом в систему и выходом из системы, но в этом случае потребуется другое поведение. Будет ли плохой практикой справляться с этим через сеансы?

Решение из одного модуля GWT + сервлета также приводит к другой проблеме. Если пользователь переходит со страницы проекта на главную, как GWT узнает, что это произошло? Приложение не будет перезагружено, поэтому оно будет рассматриваться как простое изменение состояния. Кажется неэффективным проверять информацию о странице при каждом изменении состояния.

Кто-нибудь хочет вывести меня из туманной тьмы, которая меня окружает? :-)


java servlets gwt
person Andreas    schedule 08.03.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Я бы пошел с жетонами истории. Это стандартный способ решения таких ситуаций. Я не понимаю, что вы имеете в виду под «Трудно создать дружественный к человеку URL-адрес с токенами истории» - они кажутся мне довольно дружелюбными к человеку :) И если вы используете сервлеты для обработки URL-адресов, я думаю, что это вызовет целая страница должна быть перезагружена - то, чего, я думаю, вы бы предпочли избежать.

Во-вторых, я использую gwt-presenter, и этот подход будет означать, что нам нужно поддерживать подместы в одном токене, чего я бы предпочел избежать.

Если вас не устраивает gwt-presenter (как и я :)), разверните свои собственные классы, чтобы помочь с MVP - это действительно просто (вы можете начать с нуля или изменить классы gwt-presenter), и вы получите решение, соответствующее вашим потребностям. Я сделал именно это, потому что gwt-presenter казался мне "сложным" / сложным - для общего, когда все, что мне было нужно, это подмножество того, что он предлагал (или пытался предложить).

Что касается идеи нескольких модулей - она ​​хороша, но я бы рекомендовал использовать Разделение кода - этот тип ситуации (страницы / приложения, которые можно разделить на «автономные» модули / блоки) - это именно то, для чего он предназначен, плюс вы загружаете свое приложение только один раз, поэтому дополнительный код не загружается. при переключении между страницами. Кроме того, таким способом должно быть проще делиться состоянием (например, через шину событий).

person Igor Klimer    schedule 08.03.2010
comment
Я согласен с тем, что жетоны истории кажутся интуитивно понятным выбором, но я все еще не уверен, что он оптимален :-). Что я имею в виду под нечеловеческими URL-адресами, так это то, что история GWT ставит перед токеном префикс # (который большинство пользователей не запомнит). Кроме того, поскольку пользователи обычно ожидают, что URL-адрес будет состоять только из /, мне нужно будет использовать / как разделитель места и параметра, что трудно поддерживать. Или мне здесь не хватает чего-то связанного с обработкой истории? Я согласен с тем, что с этим решением будет иметь смысл разделение кода. - person Andreas; 08.03.2010
comment
Мне не до меня доходит до того, что пользователи запоминают URL-адрес (но опять же, я не знаю, над какой страницей вы работаете и кем могут быть пользователи) - я не думаю, что кто-то пытается вспомнить В настоящее время URL-адреса, а не при наличии таких сайтов, как del.icio.us, люди добавляют в закладки сайты, которые они часто посещают. Кроме того, хэш / # в адресе - это не то, что придумал Google, это стандартный способ использования и поддержки всех браузеров, обычно относящийся к id элемента DOM, но в случае веб-приложения - к его состоянию. Gmail использует его, как и все большее количество веб-сайтов. - person Igor Klimer; 08.03.2010
comment
Возможно, ты прав. Возможно, я прилагаю слишком много усилий для создания дружественных URL-адресов. Для Gmail это не имеет никакого значения, поскольку вы всегда получаете доступ к основному сайту. В моем случае пользователи в 90% случаев переходят прямо на страницу проекта, поэтому я думаю, было бы неплохо, если бы это был естественный URL-адрес, например site.com/project/theproject вместо чего-то вроде site.com/#page=project&name=theproject. Я немного передумаю этот подход :-). Спасибо за ваш вклад. - person Andreas; 08.03.2010
comment
В качестве компромисса вы можете настроить правила перезаписи в конфигурации вашего HTTP-сервера (Apache, nginx и т. Д.), Чтобы при переходе пользователя на example.com/someurl он / она перенаправлялся на example.com/#someurl. Через некоторое время вы должны заметить, что использование # адресов будет выше, поскольку пользователь будет связывать их друг с другом. Кстати, site.com/#page=project&name=theproject громоздко, поэтому я предпочитаю (и, похоже, Google тоже - см. Gmail) использовать формат site.com/#page/project/theproject - затем вы просто разделяете его на / и обрабатываете полученные токены. - person Igor Klimer; 08.03.2010

arrow_upward
-2
arrow_downward

Основываясь на том, что вы опубликовали, я предполагаю, что вы пришли из создания веб-сайтов с использованием серверной инфраструктуры: JSP, JSF, Wicket, PHP или аналогичной. GWT не является решением для создания веб-сайтов со страничной навигацией, как в случае с вышеупомянутыми фреймворками. С GWT вы загружаете веб-приложение в браузер и остаетесь там. Обработка пользовательских событий, общение с сервером и обновление виджетов; использование gwt-presenter здесь хорошо, так как вы вынуждены думать о разделении логики контроллера и состояния просмотра. Вы действительно можете использовать все функции GWT для создания высокопроизводительного приложения в браузере, но оно определенно не предназначено для создания веб-сайтов (с использованием страниц с гиперссылками, которые передают параметры запроса через сеанс сервера. ).

Это, безусловно, наиболее часто задаваемый вопрос о GWT здесь, @ StackOverflow :) «Как мне определять страницы и навигацию между ними в GWT?» Краткий ответ: «Нет».

Вместо этого используйте Wicket, он отлично работает в App Engine и позволяет вам определять закладки страниц и все, что вы упомянули выше. Посмотрите здесь: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html

person Jeroen    schedule 08.03.2010
comment
Если бы у вас не было нескольких URL-адресов, вы не смогли бы использовать такие функции, как ограничения безопасности, соответствующие шаблону URL-адреса. code.google.com/appengine/docs/java/config/ - person Michael Munsey; 07.09.2011