Posting to fluid-work after bounce... On Jun 22, 2008, at 5:27 PM, Noah Botimer wrote:
> A couple of additional details and thoughts... > > The mod I did with SimpleModal was to primarily to achieve a "full- > screen" mode for some authoring work. This is for editing pages > within a portfolio (stored as metaobj Forms), where the final > viewed content gets a whole window. This was not the case with the > standard editing mode for Forms (a bunch of additional metaobj > markup/buttons in an iframe), so many things that would work in a > skin for the portfolios would not work in the authoring mode. > > The idea here is a high fidelity, WYSIWYG authoring experience. > The skinned portfolios were going to get a whole window, so the > only way to replicate this properly is to give the authoring mode a > whole window. So, the primary modal stuff I've worked on is > leveraging an iframe in a huge dialog and using script to > communicate back to the controlling frame behind. The iframe > source is really just a static page with a structural HTML wrapper > matching the portfolio skeleton, a skin, an FCKeditor, and some > buttons to fire a done-editing event. > > The nature of this work may be pretty different from a general case > where a "dialog box" is really needed -- maybe a div with a couple > of widgets, but nothing too complex. There are, however, some > common considerations, such as the portal frame not loading > specialized CSS to drive the styles of your dialogs. It may be > simpler in many cases to adjust the positioning code to deal with > the visible part of the tool iframe than to jump all the way out > and take on different problems. > > I've also done some work with another jQuery plugin called > Impromptu. It seems pretty good and handles some of the typical > dialog box stuff automatically (yes/no buttons, etc.) In general, > SimpleModal felt a little more natural to me, but YMMV. > > One thing that none of the plugins/libraries do (well, at least) > that I'm aware of is blocking the background input gadgets. Things > like access keys in the frames and tab targets still get picked up. > > A technique that I've used (in tandem) to great effect is to hook > the onbeforeunload event. In cases where it's really unsafe to > click away or use the back button, etc., it can save a lot of lost > work. I actually set a flag when either the save or cancel button > gets pressed and allow those through -- everything else gets the > browser's standard "do you want to navigate away?" box with a > custom message. I think this is a necessary safeguard, no matter > what dialog technique is used. > > Thanks, > -Noah > > On Jun 22, 2008, at 4:18 PM, Jim Eng wrote: > >> In the authoring environment for Sakaibrary's Subject Research >> Guide tool, there are a few places where we need a modal dialog. >> We have been using the jquery.simplemodal.js plug-in for that >> (http://www.ericmmartin.com/projects/simplemodal/). It works >> pretty well but there are some open issues. In another project, >> Noah Botimer is using the SimpleModal plug-in and has outlined >> some changes he made to fix some of the issues we're having. I >> haven't had a chance to look at Noah's work yet. >> >> I am writing to inquire whether anyone else is working on similar >> issues in sakai or implementing modal dialogs in other ways. My >> hope is that we can agree on a standard approach to modal dialogs >> across sakai that will not have the problems we've encountered. >> >> Here's a brief description of the issues we are having: When >> launched, SimpleModal covers our current document with a grey >> overlay (in a div) and shows the modal dialog in the center of >> that overlay. There are two problems with the way we have >> implemented that using the SimpleModal plug-in. First, our >> document is in an iframe, so only that part of the UI is greyed- >> out. Ideally the entire sakai UI would be covered to make the >> dialog more fully modal (i.e. the user would need to dismiss the >> modal dialog before initiating some action within sakai but >> outside the modal dialog). Also, the modal dialog is centered in >> the overlay, which may extend well beyond the visible portion of >> the document in the browser window. The user may need to scroll >> up or down to see the modal dialog. I think it's likely that this >> is a problem in our configuration of the plug-in, but I haven't >> yet seen a way to fix that (still need to look at Noah's work to >> see whether this is addressed there). Our most immediate need is >> to fix the positioning of the modal dialog so the user doesn't >> need to scroll to find it. >> >> My major question is whether anybody else is working with >> SimpleModal or other methods of implementing modal dialogs in >> sakai. Is there already a preferred way to do this in sakai? If >> not, does anybody have suggestions about how we should decide on a >> preferred way to do this? >> >> Thanks. >> >> Jim >> >> >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
