GWTP | complete model-view-presenter framework | SDK library

Avoid using Timer and use com.google.gwt.core.client.Scheduler instead. Then you can bind an actual scheduler in prod code, and the StubScheduler in tests.

You can make Timer works using gwtmockito, but I as you are already using injection, you really should hide any native or GWT.create call behind abstractions, and use alternative implementation for tests.

Presenter and Views are usually expensive to instantiate, so GWTP recommend to use both as a singleton, the view is unnecessary bc the presenter will keep the instance so it behaves like an inner-singleton. In that case, your current case, just reset the presenter state on one of the life cycle phases "prepareFromRequest", "onReveal" or "onReset" depending on how your view works.

Note that doing this is much easier than it looks, if your view is not in sync with your presenter, which should be your case, just move the code from the less-frequently-updated life-cycle (ex. construction or onBind) to a more-frequently-updated (ex. onReveal or onReset) then, whenever you navigate your presenter and the view is showed, this will be correctly updated and the singleton problem will get irrelevant.

If you really want to create a non-singleton presenter you can do the binding manually instead of using AbstractPresenterModule#bindPresenter. This might be a bit dangerous if you try to reference the presenter in multiple places, and also the presenter will be the same during resets, but I think it will be a new instance on each reveal.

During a nice chat at https://gitter.im/gwtproject/gwt# some really nice ideas where suggested;

The basic idea is to just check the URL and then start a different root panel (desktop or dashboard). One step further this different desktop/dashboard implementations can be achieved with multiple modules (with different URL's) in the project (like the tbroyer archetype) enabling the possibility to use modules with shared functionality.

Another approach would be to decide which permutation to provide after checking the URL. This would just be a variation on the current GWTP formfactors implementation;

https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-mvp-client/src/main/resources/com/gwtplatform/mvp/FormFactor.gwt.xml

Shows how GWTP defines their property to control different formfactors the class in the "property-provider" tag will generate the JS that actually selects a value (i.e. how does the .nocache.js know which device it is running on).

https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-mvp-client/src/main/resources/com/gwtplatform/mvp/rebind/linker/formFactor.js

Is the guts of it, supporting both a "if it matches these browsers, we are mobile" sort of thing, plus also the ability to override it from the URL and specify which should be used, for debugging and such (or "request desktop site")

Colin Alworth

Instead of using logic to figure out which kind of browser is running, just check window.location.hostname etc. to see if it contains desktop vs dashboard

There's a difference between using com.gwtplatform.mvp.client.PresenterWidget and com.gwtplatform.mvp.client.Presenter when implementing your own presenter classes.

When using Presenter (with a PresenterProxy), GWTP handles the presenter as singleton.

Problem is that to determine if slot and child.slot is equal, GWTP implementation uses direct comparison, meaning object references must be equal. In the GWT 2.7 and GWTP 1.4 you could send String as slot, like removeFromSlot("SOME_SLOT", widget) and this would work, since mthod was removeFromSlot(Object object, PresenterWidget w).

With new version, this method was deprecated and one would have to pass Slot object to method instead...and since I don't have these Slot objects saved and instead have them created on runtime by widget id, removeFromSlot() slot comparison fails.

Solution would be to save Slot references when widget is created with method setInslot() or maybe there already is way to retrieve widget slot...

In general using == to compare objects is not advisable. It would be so easy to fix my problem if equals() was used instead.

Some RPC classes were using incorrect import, which worked with GWTP 1.4, but did not work with GWTP 1.6.

changed

The "cookie part" of the security mechanism that you describe is not something that GWTP concerns itself with; that is part of what the programmer needs to do.

The article that you linked describes ONLY how you can say "when someone tries to access this particular Presenter/Widget, ask this particular class (a Gatekeeper) if it is allowed". That's it. It is your responsibility to bring client-side whatever info you need about your users, such as roles, etc.

And yes, documentation is pretty scarce. However, I've just finished implementing this Gatekeeper stuff in our apps, and I've found the example here very useful.

Found a solution but not the reason.

As I meantioned in the comments of the question, I used the quickstart archetype. I did not changed anything in my pom but in the .gwt.xml:

See RegExp.$1-$9, the RegExp.$1 property is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

What you should do is assign a new value to a new var, then, after replacing, check if old string is equal to a new string, and if not, the replacement was performed, else, it was not.

Use something like