Hi Thomas, thanks for your clarifications. Our scenery is a server side
OSGI application, where application modules are hot deployed and contains
their own GWT views and EntryPoints.
Our main client GWT application has a dynamic side menu, with hyperlinks
pointing to tokens associated with the external EntryPoints having views
rendered in a main region.
SIDE MENU
|
V
-------------------------------------------
| A1 | |
|------ | |
| A2 | |
|------ | |
| B1 | |
|------ | MAIN REGION |
| B2 | |
|------ | |
| C1 | |
|------ | |
| C2 | |
-------------------------------------------
What is the right approach to solve this kind of application?
Thanks in advance.
- Cristian Rinaldi
- Andres Testi
El miércoles, 12 de septiembre de 2012 05:49:41 UTC-3, Thomas Broyer
escribió:
>
>
> On Wednesday, September 12, 2012 12:53:58 AM UTC+2, Cristian Rinaldi wrote:
>>
>> We have an application with multiple EntryPoints. Each EntryPoint
>> contains an MVP configuration with their own PlaceHistoryHandler,
>> PlaceHistoryMapper and PlaceController. Depending on the order that the
>> history handlers were configured, the place treatment is overlapped. I
>> think the problem is raised because the implementation of
>> PlaceHistoryHandler invokes PlaceController.goTo(NOWHERE) when the
>> PlaceHistoryMapper do not find the place, because this place is associated
>> with the PlaceHistoryMapper of another EntryPoint. How I can solve this
>> problem? It is right to use MVP with multiple EntryPoints?
>
>
> First, Places (and Activities) have nothing to do with MVP.
>
> To answer your question, I'd rather say it's not quite right to load
> several distinct apps in a page that tweak the URL and react to its
> changes, independently of the others. The thing is, the URL -as its name
> says- represents some "location" (hence the name "place" in GWT), and if
> you have several independent things on a page, there's no nothing like
> *one* location for the whole thing. You could use a "complex" URL
> containing the "state" of each subparts (e.g.
> moduleA=a&moduleB=b&moduleC=c), but that would be suboptimal in terms of
> user experience (back to the UX of frames, except with a bookmarkable URL).
>
> Let's imagine for a second that you make your apps work by "ignoring"
> unknown places (that's what you were looking for right? avoiding the
> goTo(NOWHERE) -or whatever is your default place actually- when
> PlaceHistoryMapper doesn't understand the history token?).
>
> 1. the app loads and displays A1, B1 and C1
> 2. user navigates in each module:
> 1. A2, B1, C1 => URL is #A2
> 2. A2, B2, C1 => URL is #B2
> 3. A2, B2, C2 => URL is #C2
> 3. user uses his browser's back button => URL is #B2; nothing changes
> on screen, because module B is already at B2, and modules A and C ignore
> the place
>
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/SARMjNog9JoJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
