Несколько «страниц» в GWT с удобными для пользователя URL

Question

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

Исходя из того, что вы опубликовали, я предполагаю, что вы пришли от создания веб-сайтов с использованием серверной инфраструктуры: 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