>-----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
>> >
>>
>>

Reply via email to