Popups addiction

First off, when I talk about popups, I'm NOT talking about popup ads, or popup browser windows, but rather modal windows within the canvas. Techniques like lightbox, greybox, and jQuery UI's Dialog. These give us 'application-like' modal windows within the browser, completely provided by javascript, in order to give our users elegant views of content, sometimes through Ajax.

There have also been Drupal modules whose goals have been to integrate these display techniques and make them easier for us to utilize within our sites (@see Lightbox2, Greybox, jQuery UI). But I think it's safe to say that none of these really scratch the surface of a full-fledged API that allows you to fully integrate these into your site in a... shall I say... 'sexier' way than Popups API.

I'm not going to reiterate what you can simply find for yourself within the README, (yes, that's a popups link!) but I would like to show you a some of the more impressive things you can do with this sexy little beast and why you should use it.

Spice up your login screen

First off, here is the simplest way to accomplish putting something within a popup. We first go to our Popups Setting page and check the 'Scan all pages for popups links.' checkbox.

Popups Settings | d6

This will make sure that the popups.js is loaded on every page load on your site, so may not be suitable for high traffic sites, but not to worry! There are other ways to implement popups, we'll get to those.

The second thing is to simply create a link to our user login page and give it the class 'popups' like so: Login
Since popups is loaded, as soon as it sees that this link has the 'popups' class, it's going to attach our behavior to it. The default style sheet also appends a little 'tick' to the link so you can quickly tell that this is a popups link with just a glance. (Note that this is done with css and can be easily subverted).

d6

Now when we sign out of our site, and click our user link, we're now presented with our login form within a popup!

d6

reloadWhenDone option

Now, the previous example isn't quite functional just yet. If you follow these steps and then enter your username and password, the popup simply closes and it seems that nothing at all has happened! You were expecting the login box to go away, or at the least, some sort of confirmation message telling you that you were logged in successfully. But nadda? Hrmph.

It turns out that popups has implemented a very clever (although not fullproof) way of replacing your content area using Ajax with the results of whatever normal action was supposed to happen within what you've placed within that popup. Sound confusing? Well, it's complex, but if you refresh your page, you will indeed see that you are logged in. It's just that the link you clicked effects more that just the content area (setup within your theme settings)

Themes | d6

and this poses a problem for instances like this where you need to effect more than the content area. For this, you want to use the 'reloadWhenDone' option. Modify your link to look like this: Login
The page will now reload as soon as you're submit the form.

"But what about symantics?!", you cry. Well there are more than one way to skin this cat. Popups provides two more ways that you can specify where, on what and how your popups should work. Those being popups_add_popups() and hook_popups(). See the README for more information on how to use these. By the way, hook_popups is my favorite. ;)

Skins

Skins are not fully supported yet, but I've created a patch and example on how this can be accomplished, along with using an example skin that will make your popups look just like Facebook's popup style. Check out this issue for more, test it out, and give your feedback there. (@see Popups Skins - Facebook looking popups)

Comments

Page reload

What's the difference of using

on-popups-options="{reloadWhenDone: true}

instead of

class="popups popups-form-reload"

Re: Page Reload

The difference is that class="popups-form-reload" is more semantic than a proprietary property. I was simply using the on-popups-options as an example, but thank you for pointing this out! This is also described along with other classes within the README.

Thank you for your site. I

Thank you for your site. I have found here much useful information.

fancybox

Don't forget about fancybox ;) It's the fanciest one and it's Jquery too.

Re: fancybox

I didn't forget it, I simply had never heard of it ;) Plus I don't see a Drupal project for it so it wouldn't have made my list anyway, but thanks for pointing out another great looking technique! It would make a nice Popups skin as well :)

This is exactly what I've been waiting for

Very nice! I'll be recommending this module! Thanks!!

Excellent write up

Hi Jerad,
Thanks for the excellent write up, and the patch (I am looking forward to checking it out). And it was cool meeting you and your gang at the SFDUG.

And you are right, class="popups-form-reload" and on-popups-options="{reloadWhenDone: true} do exactly the same thing. Some of the other options that are too complicated to be aliased by a simple class.

Wysiwyg API

I not only want to eliminate that "LIMITATIONS" chapter in your README.

I even(-tually) want to go a step further: Wysiwyg API is in the need for a consistent popup/modal dialog API to support editor plugins/buttons that require an interface to insert or edit content in the editor. For example, Image Assist (the only next-generation Wysiwyg API plugin as of now) implements a modal to browse existing images, upload a new one, select an image, configure it, and finally insert the image into the editor. This button can appear in the toolbar of TinyMCE, FCKeditor, any other editor, or even for plain textareas.

Since each editor implements its own madness for handling modal dialogs, or might not even support dialogs at all, I considered whether Popups would be a viable option to build upon.

If you think it is, I could use some hand-holding to integrate it properly. :)
(which will probably mean that modules like Image Assist or even Wysiwyg API itself will add a dependency on Popups module)

Re: Wysiwyg API

God knows I'm all for API's, but I really tend to shy away from making them dependencies. In cases like Popups where it's completely dependant upon javascript already, I think taking an approach that we usually take when dealing with javascript is more appropriate. That being, make it work without, then add it in as an extra flair. So the fact that most WYSIWYG plug-ins already have their own modal dialogs, there is no need for a dependecy IMO, but if someone has Popups API enabled, then maybe it would use that instead. In which case hook_popups() is awesome for this since pretty much any integration can be in encompased here and if you do need to add some extra Drupal.behaviors, simply check if (Drupal.popups) { exists and they'll only be called when Popups is enabled.

I'd be glad to look at this at some point, but davexoxide is more familiar with Wysiwyg API so maybe I'll 'encourage' him to look into it ;)

Re: Popups for Wysiwyg API

JavaScript degradation is not the issue. Client-side editors do not work without JavaScript anyway.

The issue is that each and every editor implements its own popup handling, which we would have to grasp in-depth and independently to provide a generic interface for other Drupal contrib modules. To give you an example, TinyMCE either opens a popup window or a modal dialog depending on a configuration setting. A Drupal plugin would have to find out in which kind of document it is living in and how to access other Drupal properties from there. That not being complex enough, TinyMCE *wraps* the content for the modal dialog/popup window into another IFRAME in some cases... So, this is just TinyMCE. I don't want to know what other editors do.

Instead, Wysiwyg API will provide its own modal dialog handling. Whether that will depend on Popups API or not, I don't know yet - but trying to find out. All I know is that Wysiwyg API will implement another layer of indirection in front of it, because it has wrap the popup/modal functionality into its own application programming interface (API).

Daniel F. Kudwien

API's

Hi Sun,
The whole point of my trying to create an api (vs just a random module) is to make it easy for other modules to build on top of it. So I am happy to build any needed additional functionality or interfaces for you. I haven't played with IFRAMES much, so I don't know if my current approach works for them or if they need special handling.
Jared is right that Popups is currently optimized towards being an enhancement rather than a requirement. But if a module needs/wants popup form handling it seems silly for them to re-invent the wheel vs requiring another module.
So what's the first step?

This is awesome.... It's

This is awesome....
It's really helpful for newbies like me...
If it is possible can you post few more examples
how to use popups with row edit and delete buttons.

Thanks.