Extended Presenter Lifecycle

63 views
Skip to first unread message

Harald Pehl

unread,
Nov 28, 2014, 8:02:54 AM11/28/14
to gwt-pl...@googlegroups.com
I'd like to make a proposal for an extended presenter lifecycle. Let me give some backround about my motivation for that: In our current project we need to fetch data from the server side before the actual presenter lifecycle starts: We populate a security context with data from the server side. The security context is crucial for our presenters and needs to be intialized right at the start of the lifecycle.  

Our current solution for that is to use a custom placemanager and override com.gwtplatform.mvp.client.proxy.PlaceManagerImpl.doRevealPlace(). In the overridden doRevealPlace() method we make an async call and make a call to super.doRevealPlace() in the onSuccess() callback. However it feels like a hack and for me this belongs more to the presenter / proxy lifecyclde than to the placemanager. 

I'm not sure whether a custom proxy is the right tool for such a scenario. The documentation for custom proxies [1] does not give much details when to use them. I know about the AsyncCall*Event events, but they lack the information about the name token / presenter. 

So my proposal would be to extend the presenter's lifecyle to a phase where you can make async calls. 

Is this an issue which other GWTP users are facing as well? What would a solution for that look like?  


.: Harald

Richard Wallis

unread,
Nov 28, 2014, 8:06:14 AM11/28/14
to gwt-pl...@googlegroups.com
Does manual reveal not cover your use case https://github.com/ArcBees/GWTP/wiki/Presenter-Manual-Reveal ?

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Heiko Braun

unread,
Dec 1, 2014, 2:21:55 AM12/1/14
to gwt-pl...@googlegroups.com


I think Harald need's the information _before_ the view is initialised (I think before onBind()). AFAIK manual reveal is invoked after the view was initialised.

Harald Pehl

unread,
Dec 2, 2014, 3:00:54 AM12/2/14
to gwt-pl...@googlegroups.com
Yes manual reveal seems like a reasonable solution for that. Totally forgot about that feature. 

Thanks Richard for the hint!

Harald Pehl

unread,
Dec 11, 2014, 2:44:23 PM12/11/14
to gwt-pl...@googlegroups.com
After some more prototyping with manual reveal, it turns out that Heiko's objections are valid. In our context fetching the data from the server in manualReveal() is too late. We need to have the information at hand before the presenter lifecycle starts. That is to say before the presenter is even loaded by the proxy. 

Looking at the code it tunrs out that the presenter is loaded by the proxy using an instance of IndirectProvider<P>. The concrete instance which is used depends on the kind of proxy (@ProxyStandard, @ProxyCodeSplit or @ProxyCodeSplitBundle) and is generated using deferred binding. I patched the code generation for the proxy in a way that you can specify your own custom provider which is used instead of the default ones provided by GWTP. 

I think this could be a useful extension to GWTP which makes the presenter resolution more flexible without modifying the current default behaviour. I'm about to open a PR to discuss the implementation details.

.: Harald

Christian Goudreau

unread,
Dec 12, 2014, 3:30:30 PM12/12/14
to gwt-pl...@googlegroups.com
Makes a lot of sense to me and seem even easier than creating your own proxy! (Which we usually do with dynamic presenters)

Christian Goudreau | CEO - Président

Harald Pehl

unread,
Dec 15, 2014, 3:32:22 AM12/15/14
to gwt-pl...@googlegroups.com
The related PR is open for discussion: https://github.com/ArcBees/GWTP/pull/652

.: Harald
Reply all
Reply to author
Forward
0 new messages