On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <[email protected]> wrote:
> 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? >> > Ok, I think I have most things working again however I'm seeing something weird and I don't know if it's tied to this or not. For some reason all my gadget frames in Rave are the correct sizes but all the iframes inside the frames have a fixed width of 320px (so they don't fill the frames). I don't see this problem on the Rave demo site but I don't know what could be causing it in my environment all of a sudden. Any thoughts? >> > >> > > >> > > Chris >> > > >> > >> > >
