I believe that I dropped some logic that was hard coding iframe sizes in js. The assumption being that javascript shouldn't be sizing anything from the container side - it should just be a css rule. The only exception should be calls through the gadget api or preferred height / width as defined in the gadget xml.
On Wed, Mar 27, 2013 at 9:55 PM, Chris Geer <[email protected]> wrote: > 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 > >> > > > >> > > >> > > > > >
