On 28 March 2013 16:47, Chris Geer <[email protected]> wrote: > On Thu, Mar 28, 2013 at 7:42 AM, Jasha Joachimsthal <[email protected] > >wrote: > > > Thanks Chris. Is there a reason why you added it to the wiki and not to > the > > documentation section in the site? > > > > Nope, just first place I thought of. I just wanted to make sure it was > somewhere. >
Better somewhere than nowhere :) > > > > > On 28 March 2013 14:51, Erin Noe-Payne <[email protected]> wrote: > > > > > Excellent, thanks Chris. > > > > > > > > > On Thu, Mar 28, 2013 at 12:25 AM, Chris Geer <[email protected]> > > > wrote: > > > > > > > I went ahead and copied the JS Documentation from the review to the > > wiki > > > > [1]. It need some more formatting but it will do for now. > > > > > > > > [1] http://wiki.apache.org/rave/JSAPI > > > > > > > > On Wed, Mar 27, 2013 at 9:09 PM, Chris Geer <[email protected]> > > > wrote: > > > > > > > > > On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne < > > > > [email protected]>wrote: > > > > > > > > > >> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin < > > > > [email protected] > > > > >> >wrote: > > > > >> > > > > >> > 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 > > > > >> > > > > > >> > > > > >> I did. > > > > >> > > > > > > > > > > Thanks for the pointer Erin. I found the issue on my side with the > > 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 > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
