On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <[email protected]>wrote:
> On Wednesday, March 27, 2013, Chris Geer wrote: > > > I'm struggling with the new JS API quite a bit while trying to integrate > it > > into my application. It's turning into a lot of trial and error about > what > > functions were renamed and what functions were removed or don't seem to > > work. I like the new approach but I'm concerned that we've lost > > capabilities and I'm not sure how we test for that. > > > I have seen a couple of things missing. > > Definitely a few things were lost in transition, especially from the portal functionality side. One example would be the whole concept of mobile ui. Ideally we don't want to lose any core functionality. > > > > > My latest two struggles are: > > - Registering custom popups: There used to be a method called > > rave.registerPopup that would allow for a custom popup definition to be > > added. That seems to have gone away and now the popups seem to be > > registered privately. I'm not sure if just adding a popup as a new view > is > > good enough or not. > I didn't call this out clearly enough, but popups now use the new registerView functionality. The idea is that rave core doesn't know anything about the ui but it generically supports the registration and use of view objects that widgets can be rendered into. So when your gadget makes an openviews call to render in "modal" or "asdf", rave attempts to render into a registered view with the matching name: https://github.com/apache/rave/blob/trunk/rave-portal-resources/src/main/webapp/static/script/core/rave_opensocial.js#L92 You need to refactor your popup definitions slightly to confirm to the new register view spec. Rave portal registers that same 3 popup views as before, but you can override by registering your custom view with the same name. For reference you can see how I tied the existing gadget definitions into the new api - honestly it is not the best approach but it was the quickest way to get our current portal code to plug in to the new api: https://github.com/apache/rave/blob/trunk/rave-portal-resources/src/main/webapp/static/script/portal/rave_ui.js#L871 > - Provider Initialization: We make big use of the initialization chain by > > calling rave.registerOnProvidersInitizalizedHandler(). This method still > > exists and looking at it, it seems to add the callback to an array. The > one > > thing I don't see when those callbacks are actually called. It used to be > > called after the open social provider was complete. At the moment, those > > callbacks are never triggered. > Ok, so the fact that that function exists is a mistake. Previously we had 4-5 lifecycle registration events but only one was actually being used. Also there wasn't much value in lifecycle events when the only event of significance is before and after rendering (if this not accurate let me know). All the callbacks should now be condensed to rave.registerOnInitHandler(), which will be triggered when you make your call to rave.init(), after init of providers and widgets. I accidentally included those register functions when I factored out rave_portal code. > > > > It very well might be I'm just not understanding how things were > > restructured, but if I'm having problems, I know other people will to. > It's > > almost like we need a migration document (especially to list methods that > > no longer exist or have moved). > > > This would be nice, but documentation on how to use the new API and in what > scenarios would probably suffice. > > There is fairly detailed documentation of the new api that I wrote and posted here: https://reviews.apache.org/r/9993/ I'm currently writing that documentation as comments into the code - we should look at adding api docs on our site? > > > > > Chris > > >
