On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <[email protected]>wrote:
> 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. > It happens during any major transition, it's expected. Like I said, I just don't like the fact we can't easily detect the issues. > > > > > > > > > > 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. > Ok, that makes sense. I can switch my code over. > > > > > > > > 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/ This is perfect. It's the one place I didn't think to look for the documentation. I remember you saying you did some (and I thought I saw it) but I couldn't find it. > > > I'm currently writing that documentation as comments into the code - we > should look at adding api docs on our site? > > > > > > > > > Chris > > > > > >
