Hey Chris, Your popup definition looks good (except maybe for the pubsub setup?). Glad it's working for you now.
Regarding pub/sub, obviously I don't know your entire use case. But what kind of events are you trying to capture? If it is the jqui events that effect the dialog - drag / resize / focus - then your approach might be correct. (I'm actually not sure, normally I think of pub/sub as inter-gadget communication; what you are doing is really rave-to-gadget communication.) But if you care about what's happening IN the popup, I would suggest that it's not the job of the popup container to manage pubsub or eventing. Here all we are doing is creating the dom element that will hold the new gadget being opened. If you want to know what's happening inside the iframe, then you should manage that from within the gadget definition, and do all the pubsub stuff there. >-----Original Message----- >From: Chris Geer [mailto:[email protected]] >Sent: Wednesday, May 09, 2012 9:32 PM >To: [email protected] >Subject: Re: [DISCUSS] OpenViews Modal > >Erin, > >On Wed, May 9, 2012 at 10:36 AM, Noe-Payne, Erin A. ><[email protected]>wrote: > >> > >> >Erin, >> > >> >Thank you for the clarification, I was misunderstanding some of the logic >> >so you are correct, there isn't a change needed to rave.js to support >> using >> >other popup implementations. Did I mention I'm not a javascript expert? :) >> >> Not a problem, glad to help. >> >> > >> >As to the last point, my question was really in regards to registering for >> >events from the popup itself from within the gadget. I think your point is >> >that isn't possible, which makes sense. >> >> It isn't impossible, but it isn't going to happen through gadgets.views. >> For whatever events you care about in your popup, you'll need to capture >> them in your popup through whatever script is running in that distinct >> gadget. Then you can use the gadgets pubsub ( >> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core- >Gadget.xml#interGadgetEventing) >> to publish those events, and have your initiating gadget listen and react >> as needed. >> > >This has been more challenging than I thought it would. What I really want >to interact with is the popup, not the initiating gadget, to get button >events from the popup wrapper. I have finally got it working but I had to >essentially use pubsub from the container using >rave.getManagedHub().publish/subscribe. This works except it caused a >problem in the onPublish/onSubscribe event handlers that log events. If >that is the right way then I've got a fix that works, if there is a better >way for the container to participate in pubsub I'd love to know about it. >I've included my popup definition below so you can see what I've trying to >do. > > >> >> > >> >Another question I have is how does one close a popup? My thought was I >> >could call gadgets.views.close(); which does successfully destroy the data >> >inside the popup but the cleanup method on the popup isn't called. What >> >triggers the cleanup method that is defined as part of the popup? I've >> >never seen that called. >> >> Calling gadgets.views.close() should cause a popup's cleanup function, if >> it exists, to be closed. >> The callstack will look like gadgets.views.close() -> >> container.views.destroyElement() -> rave.destroyPopup() -> >target.cleanup() >> You can set breakpoints at rave_opensocial.js line 109 and rave.js line >> 425 if you want to track it down. If you are seeing a condition where >> cleanup exists and is not getting called, that is probably an issue that >> should be opened. >> Note that if this is only happening with respect to your custom defined >> popups, you should redo the markup as I explained and take out your >> modifications. The cleanup relies on having the proper dom element - it's >> possible your changes through a wrench in that. >> > >You were right, it was an issue with my custom popup. Got it working now. > > > >var jquery_modal = { > name:"jquery_modal", > containerSelector:'.ui-dialog-content', > contentSelector:'.x-dialog-content', > markup:'<div class="ui-dialog-content"><div >class="x-dialog-content"></div></div>', > initialize:function (container) { > container.find(this.contentSelector).data('popupType', this.name >); > var cfg = { > modal:true, > width:1024, > closeOnEscape:false, > stacks:true, > buttons: [{ > id: "btnSave", > text: "Save" > }, { > id: "btnCancel", > text: "Cancel", > click: function() { > > rave.getManagedHub().publish($(this).find("iframe").get(0).name, "Test"); > } > }] > }; > container.dialog(cfg); > > var subID = rave.getManagedHub().subscribe(this.name, function >() { > alert('dialog message'); > }); > > container.on('dialogclose', function () { > rave.getManagedHub().unsubscribe(subID); > container.dialog('destroy'); > container.detach(); > }); > }, > cleanup:function (content) { > var container = content.parents(this.containerSelector); > > container.dialog('close'); > }, > singleton:false > } > >> >> > >> >Thanks, >> >Chris >> > >> >On Wed, May 9, 2012 at 8:38 AM, Noe-Payne, Erin A. <[email protected]> >> >wrote: >> > >> >> >> >> >-----Original Message----- >> >> >From: Chris Geer [mailto:[email protected]] >> >> >Sent: Wednesday, May 09, 2012 10:53 AM >> >> >To: [email protected] >> >> >Subject: Re: [DISCUSS] OpenViews Modal >> >> > >> >> >Thanks for the pointer to the backdrop: static option. That is a step >> in >> >> >the right direction. >> >> >> >> Just want to make sure I was clear. You should not have to deal with >> that >> >> variable, it has already been done in the current rave implementation. >> If >> >> you make the following call you should get a modal dialog popup with the >> >> static background set that will not close on an outside click / esc key >> >> press: >> >> gadgets.views.openGadget(returnCallback, onOpenCallback,{ >viewTarget: >> >> 'modal_dialog' , view: 'my_view_name' }); >> >> >> >> >I'm still with Matt though that implementors should >> >> >have the ability to use something other than bootstrap if they want, >> >> unless >> >> >bootstrap is in the process of adding a lot more features very soon. >> >> > >> >> >Unfortunately, I couldn't find a way to spawn different dialog types >> >> >without having Rave know about bootstrap and jquery. >> >> >> >> I don't follow here. As long as the library you want to use is included >> on >> >> the page, you should be able to write the appropriate script into your >> >> custom popup's initialize and cleanup functions. If that has not been >> your >> >> experience we should open a ticket. >> >> >> >> >I am not a javascript >> >> >expert so maybe someone else can look at it and make a suggestion. >> Right >> >> >now this is what I've done. I've changed the last line in the >> createPopup >> >> >method to be this: >> >> > >> >> > if (target.popupType == 'jquery') { >> >> > return container.get(0); >> >> > } else { >> >> > return container.find(target.contentSelector).get(0); >> >> > } >> >> > >> >> >If you define a variable called popupType on your popup definition you >> can >> >> >select to use a jquery dialog instead of the bootstrap modal. Maybe if >> we >> >> >add another method to the popup definition that could return the >> correct >> >> >root node we could get rid of this? >> >> >> >> This shouldn't be necessary. Instead when you define your custom >popup, >> >> write the markup so that it has two nested components. A div that acts >> as >> >> the container, and then a div inside that will hold the content. Write >> your >> >> selectors accordingly. You can follow the example of the hardcoded >> popups >> >> for this. >> >> >> >> > >> >> >The last thing I can't figure out is how to attach functions to the >> dialog >> >> >events from the gadget loaded in the popup, not the popup definition. >> For >> >> >example, we want to use this for users to edit information. We need to >> be >> >> >able to popup a "Are you sure you want to cancel as you'll lose your >> >> >changes" but we only want to do it if they've made changes. That >> requires >> >> >the function to have access to data in the popup that is loaded. I >> haven't >> >> >tried this yet but maybe we could add a view_param option when we >open >> >> >the >> >> >dialog that would tell the gadget it's running inside a popup and give >> it >> >> >the name of the element to lookup to attach functions? Not sure if that >> >> >would work, maybe I'll try. >> >> >> >> Again, not sure if I'm following but I'll try to answer. Your popup is >> a >> >> separate gadget from the initiating gadget. By default they are only >> able >> >> to communicate between each other at the time the popup is opened >(any >> >> values passed through the opt_params.viewParams object are available >in >> >the >> >> popup as view params as described in the opensocial spec) and when the >> >> popup is closed (from within your popup if you want to set the return >> value >> >> you will use gadgets.views.setReturnValue(retVal) and this data will be >> >> handed back to the initiating gadget as the argument of your >> >> onCloseCallback(retVal) at the time the popup as closed). If you want >> them >> >> to talk to each other more, you will need to use pupsub communication. >> >> >> >> This behavior is documented in a semi-understandable way at >> >> http://opensocial-resources.googlecode.com/svn/spec/trunk/Core- >> >Gadget.xml#gadgets.views.openGadget. >> >> Hopefully this actually addresses your questions? >> >> >> >> > >> >> >Chris >> >> > >> >> >On Wed, May 9, 2012 at 6:59 AM, Franklin, Matthew B. >> >> ><[email protected]>wrote: >> >> > >> >> >> >-----Original Message----- >> >> >> >From: Noe-Payne, Erin A. [mailto:[email protected]] >> >> >> >Sent: Wednesday, May 09, 2012 9:06 AM >> >> >> >To: [email protected] >> >> >> >Subject: RE: [DISCUSS] OpenViews Modal >> >> >> > >> >> >> >>-----Original Message----- >> >> >> >>From: Franklin, Matthew B. [mailto:[email protected]] >> >> >> >>Sent: Wednesday, May 09, 2012 8:22 AM >> >> >> >>To: [email protected] >> >> >> >>Subject: RE: [DISCUSS] OpenViews Modal >> >> >> >> >> >> >> >>>-----Original Message----- >> >> >> >>>From: Chris Geer [mailto:[email protected]] >> >> >> >>>Sent: Tuesday, May 08, 2012 11:25 PM >> >> >> >>>To: [email protected] >> >> >> >>>Subject: [DISCUSS] OpenViews Modal >> >> >> >>> >> >> >> >>>I've been spending a lot of time with the open_views feature. I >> >> really >> >> >> like >> >> >> >>>how things look right now using the bootstrap modal however the >> >> >> >>>functionality is just not there. The biggest problem I have is >> that >> >> if >> >> >> you >> >> >> >>>click anywhere off the dialog it automatically closes which >> doesn't >> >> work >> >> >> >> >> >> >> >>There is a flag that we can pass to the Bootstrap modal to NOT >> close >> >> on >> >> >> click. >> >> >> >> >> >> >> > >> >> >> >Correct, and that flag is being passed. Rave implements dialog and >> >> >> >modal_dialog (aka rave.opensocial.VIEW_TARGETS.DIALOG / >> >> >> >MODALDIALOG), are you using the modal version? It is receiving the >> >> >> >backdrop: 'static' flag, and should not ever close except clicking >> on >> >> a >> >> >> button >> >> >> >bound to gadgets.views.close. The standard dialog does not have >the >> >> >> static >> >> >> >backdrop. >> >> >> > >> >> >> >>>very well for users who miss click. I've been working on a mod >> that >> >> >> would >> >> >> >>>allow you to define popups that can use either bootstrap modal or >> >> >jquery >> >> >> >>>popups. >> >> >> >> >> >> >> >>IMHO implementers should be able to use whatever type of UI >that >> >they >> >> >> >>want, but it would be nice if we could support that without >> actually >> >> >> including >> >> >> >a >> >> >> >>reference to jQuery UI in the demo. The reason behind this is to >> keep >> >> >> the >> >> >> >>demo as simple as possible. >> >> >> >> >> >> >> >>Now, if implementers are unable to use jQuery UI due to some >> >decision >> >> >we >> >> >> >>made in the code, we should fix that. >> >> >> > >> >> >> >I believe the pattern that Chris put in place to extend / override >> the >> >> >> popups >> >> >> >should allow someone to use jqui or any other library. >> >> >> >> >> >> +1 >> >> >> >> >> >> > >> >> >> >> >> >> >> >>> >> >> >> >>>Are there other things we could do to make this more usable? >> >> >> >>> >> >> >> >>>Chris >> >> >> > >> >> >> >> >> >> >> >> >>
