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

Question

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

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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