On Wednesday, March 27, 2013, Erin Noe-Payne wrote: > 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.
In that case, we should update the base CSS > > > 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 >
