[Engine-devel] Update on UI Plugins: PoC patch revision 3

[Vojtech Szocs]

Hi guys, 

here comes the most recent revision of UI Plugins proof-of-concept patch (please find it attached). 

There's only one significant change on top of previous revision: the possibility to add custom main tabs :) 

    * MainTabCustomPresenter is the (non-singleton) presenter of the custom tab component 
    * MainTabCustomView is the (non-singleton) view of the custom tab component, could be improved to actually show the content of the given URL (e.g. through an iframe) 
    * MainTabCustomProxy is the (non-singleton) presenter proxy implementation 

Here's what happens when a plugin adds a new custom main tab (the process starts at PluginManager.addMainTab method): 

    * MainTabCustomProxyFactory creates new presenter proxy ( MainTabCustomProxy ) 
    * MainTabCustomProxy binds itself to the given place (so that it will be able to respond to GWTP PlaceRequestInternalEvent ), creates the "actual" proxy ( WrappedProxy ) providing actual tab data, and also connects with WebAdmin default gatekeeper (user must be signed into WebAdmin in order to access the place of this custom tab) 
    * From that point on, the presenter proxy for custom tab component is bound and ready for use 


In GWTP, when main tab panel (e.g. MainTabPanelPresenter ) renders its tabs, it fires an event ( RequestTabsEvent ) saying "any tab which belongs to me, report in". Besides the standard main tab proxies, MainTabCustomProxy instance(s) report in as well, registering themselves into main tab panel through TabContainerPresenter.addTab method. In effect, main tab panel will contain clickable tab headers for all tabs that belong to it. 



When the custom tab gets activated, or more precisely, when the custom tab presenter gets revealed (e.g. by clicking custom tab header, or programatically using PlaceManager ), GWTP will first ask all proxies "which one handles #custom-tab place", and MainTabCustomProxy indeed responds and hands over its presenter. GWTP presenter reveal flow and view composition gets triggered (bottom-up, from MainTabCustomPresenter right up to RootPresenter ), and after reaching the top of presenter hierarchy ( RootPresenter ), presenter life-cycle methods (such as onReveal , onReset , etc.) are called in a top-down fashion. 





I've tested this patch using following plugin code ( myPlugin.js ): 


pluginApi.plugins['myPlugin'] = { 
UiInit: function() { 
pluginApi.ui.addMainTab('Custom Tab', 'custom-tab', 'http://www.google.com/'); 
} 
}; 
pluginApi.ready('myPlugin'); 



As a side note, this PoC patch only adds one kind of custom main tab (the one that is supposed to have its content rendered from the given URL). We could also implement other kinds of custom main tabs, two of which come to my mind right now (this is just an idea for future improvement): 

    * custom table-based main tab, with API for adding columns, buttons and actual row data 
    * custom form-based main tab, with API for adding key-value data pairs 


Let me know what you think. 


Cheers, 

Vojtech 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20120827/4b5c4e09/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WIP-UI-Plugins-PoC-revision-3.patch
Type: text/x-patch
Size: 39483 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20120827/4b5c4e09/attachment-0002.bin>