You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Chris Geer <ch...@cxtsoftware.com> on 2013/03/27 23:52:50 UTC
New JS API
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.
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.
- 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.
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).
Chris
Re: New JS API
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 28 March 2013 16:47, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Thu, Mar 28, 2013 at 7:42 AM, Jasha Joachimsthal <jasha@apache.org
> >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 <er...@gmail.com> wrote:
> >
> > > Excellent, thanks Chris.
> > >
> > >
> > > On Thu, Mar 28, 2013 at 12:25 AM, Chris Geer <ch...@cxtsoftware.com>
> > > 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 <ch...@cxtsoftware.com>
> > > wrote:
> > > >
> > > > > On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <
> > > > erin.noe.payne@gmail.com>wrote:
> > > > >
> > > > >> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <
> > > > m.ben.franklin@gmail.com
> > > > >> >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 <
> > > chris@cxtsoftware.com>
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <
> > > > chris@cxtsoftware.com>
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > > > >> > > > erin.noe.payne@gmail.com>wrote:
> > > > >> > > > >
> > > > >> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > > > >> > > > m.ben.franklin@gmail.com
> > > > >> > > > >> >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
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: New JS API
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Thu, Mar 28, 2013 at 7:42 AM, Jasha Joachimsthal <ja...@apache.org>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.
>
> On 28 March 2013 14:51, Erin Noe-Payne <er...@gmail.com> wrote:
>
> > Excellent, thanks Chris.
> >
> >
> > On Thu, Mar 28, 2013 at 12:25 AM, Chris Geer <ch...@cxtsoftware.com>
> > 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 <ch...@cxtsoftware.com>
> > wrote:
> > >
> > > > On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <
> > > erin.noe.payne@gmail.com>wrote:
> > > >
> > > >> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <
> > > m.ben.franklin@gmail.com
> > > >> >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 <
> > chris@cxtsoftware.com>
> > > >> > wrote:
> > > >> > >
> > > >> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <
> > > chris@cxtsoftware.com>
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > > >> > > > erin.noe.payne@gmail.com>wrote:
> > > >> > > > >
> > > >> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > > >> > > > m.ben.franklin@gmail.com
> > > >> > > > >> >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
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: New JS API
Posted by Jasha Joachimsthal <ja...@apache.org>.
Thanks Chris. Is there a reason why you added it to the wiki and not to the
documentation section in the site?
On 28 March 2013 14:51, Erin Noe-Payne <er...@gmail.com> wrote:
> Excellent, thanks Chris.
>
>
> On Thu, Mar 28, 2013 at 12:25 AM, Chris Geer <ch...@cxtsoftware.com>
> 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 <ch...@cxtsoftware.com>
> wrote:
> >
> > > On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <
> > erin.noe.payne@gmail.com>wrote:
> > >
> > >> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <
> > m.ben.franklin@gmail.com
> > >> >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 <
> chris@cxtsoftware.com>
> > >> > wrote:
> > >> > >
> > >> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <
> > chris@cxtsoftware.com>
> > >> > > wrote:
> > >> > > >
> > >> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > >> > > > erin.noe.payne@gmail.com>wrote:
> > >> > > > >
> > >> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > >> > > > m.ben.franklin@gmail.com
> > >> > > > >> >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
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: New JS API
Posted by Erin Noe-Payne <er...@gmail.com>.
Excellent, thanks Chris.
On Thu, Mar 28, 2013 at 12:25 AM, Chris Geer <ch...@cxtsoftware.com> 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 <ch...@cxtsoftware.com> wrote:
>
> > On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <
> erin.noe.payne@gmail.com>wrote:
> >
> >> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <
> m.ben.franklin@gmail.com
> >> >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 <ch...@cxtsoftware.com>
> >> > wrote:
> >> > >
> >> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <
> chris@cxtsoftware.com>
> >> > > wrote:
> >> > > >
> >> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> >> > > > erin.noe.payne@gmail.com>wrote:
> >> > > > >
> >> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> >> > > > m.ben.franklin@gmail.com
> >> > > > >> >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
> >> > >
> >> >
> >>
> >
> >
>
Re: New JS API
Posted by Chris Geer <ch...@cxtsoftware.com>.
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 <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <er...@gmail.com>wrote:
>
>> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <m.ben.franklin@gmail.com
>> >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 <ch...@cxtsoftware.com>
>> > wrote:
>> > >
>> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com>
>> > > wrote:
>> > > >
>> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
>> > > > erin.noe.payne@gmail.com>wrote:
>> > > > >
>> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
>> > > > m.ben.franklin@gmail.com
>> > > > >> >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
>> > >
>> >
>>
>
>
Re: New JS API
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 8:25 PM, Erin Noe-Payne <er...@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <m.ben.franklin@gmail.com
> >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 <ch...@cxtsoftware.com>
> > wrote:
> > >
> > > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com>
> > > wrote:
> > > >
> > > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > > > erin.noe.payne@gmail.com>wrote:
> > > > >
> > > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > > > m.ben.franklin@gmail.com
> > > > >> >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
> > >
> >
>
Re: New JS API
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 10:48 PM, Matt Franklin <m....@gmail.com>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.
>
> >
> >
> > On Wed, Mar 27, 2013 at 9:55 PM, Chris Geer <ch...@cxtsoftware.com>
> wrote:
> >
> > > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com>
> > wrote:
> > >
> > > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > > erin.noe.payne@gmail.com>wrote:
> > > >
> > > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > > m.ben.franklin@gmail.com
> > > >> >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
> >
>
Re: New JS API
Posted by Matt Franklin <m....@gmail.com>.
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 <ch...@cxtsoftware.com> wrote:
>
> > On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com>
> wrote:
> >
> > > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> > erin.noe.payne@gmail.com>wrote:
> > >
> > >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> > m.ben.franklin@gmail.com
> > >> >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
>
Re: New JS API
Posted by Erin Noe-Payne <er...@gmail.com>.
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 <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
>
> > On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <
> erin.noe.payne@gmail.com>wrote:
> >
> >> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <
> m.ben.franklin@gmail.com
> >> >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
> >> > >
> >> >
> >>
> >
> >
>
Re: New JS API
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 6:04 PM, Chris Geer <ch...@cxtsoftware.com> wrote:
> On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <er...@gmail.com>wrote:
>
>> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <m.ben.franklin@gmail.com
>> >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
>> > >
>> >
>>
>
>
Re: New JS API
Posted by Chris Geer <ch...@cxtsoftware.com>.
On Wed, Mar 27, 2013 at 5:39 PM, Erin Noe-Payne <er...@gmail.com>wrote:
> On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <m.ben.franklin@gmail.com
> >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
> > >
> >
>
Re: New JS API
Posted by Erin Noe-Payne <er...@gmail.com>.
On Wed, Mar 27, 2013 at 7:08 PM, Matt Franklin <m....@gmail.com>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.
>
> >
> > 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.
> >
> > 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/
I'm currently writing that documentation as comments into the code - we
should look at adding api docs on our site?
>
> >
> > Chris
> >
>
Re: New JS API
Posted by Matt Franklin <m....@gmail.com>.
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.
>
> 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.
> - 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.
>
> 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.
>
> Chris
>