I'll post up a .patch file later today. I used custom .js for the dialog, as I wasn't sure how we'd go about integrating a 3rd party lib, and the few I looked at didn't quite fit right, or had license issues. Besides, it was good practice. However, if we have a library that we're trying to integrate with on a larger scale, then I think it makes sense.
D. On 1/30/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
HEy Danny, two things; 1) the image looks great. 2) do you use one of these days upcoming "ajax-ish" JavaScript libs? (or "custom" JS?) Another one, will you also provide the source in somewhat format? That would allow us to start with a sandbox .. Thanks, Matthias On 1/30/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > Hey, > > In a timely fashion, I've just seen Adams comments about wanting to switch > to a DHTML/iFrame solution for dialog windows. > > I've pulled together a prototype set of changes that switches the default > implementation of dialog windows, to use a floating popup iframe. It seems > to work well and both the date picker dialog and the number picker demo work > without any alteration. It is implemented as a javascript component that > inherits from the basic panelPopup component I posted a while back. The > prototype renders an iframe that blocks access to the parent window until > the dialog returns. > > I say prototype, because I need some feedback on what is/isn't allowed to > change inside the current dialog framework. Meaning - do we have to > introduce two modes of running, where dialogs will appear in either a > browser window, or in a DHTML iframe? Could we kill off the browser window > version as there seems to be a very large amount of JavaScript that we could > tear out if we did. > > I'll post a war file this afternoon demonstrating how it works, but for now > here's a quick picture and the list of changes. > http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg > > DialogRequest.java modified to call an alternative javascript method for > opening the dhtml dialog. When the dialog is launched it is populated with > the necessary properties for callback when the dialog is closed, thus no > array of dialogs (var ADFDialogReturn = new Array()) needs to be maintained. > function _launchPopupDialog( > srcURL, > features, > formName, > postbackId, > partial) > { > _theDialog.callback = _returnFromDialogAndSubmit; > _theDialog.callbackProps = { formNameKey:formName, > postbackKey:postbackId, partialKey:partial }; > _theDialog.resize(features['height'], features['width']); > _theDialog.launchDialog(srcURL); > } > > On close the dialog will call the following callback function > function _returnFromDialogAndSubmit(props, value) { > if (props) > { > var formName = props['formNameKey']; > var postbackId = props['postbackKey']; > var partial = props['partialKey']; > > if (partial) > _submitPartialChange(formName, 0, {rtrn:postbackId}); > else > submitForm(formName, 0, {rtrn:postbackId}); > } > } > > > CoreRenderKit.returnFromDialog() - modified to return the following > scriptlet, which closes the dialog and causes the above callback to occur. > <script>parent.parent.returnFromDialog();</script> > > Window.js - _sizeWin() function - disabled until I have time to rework. If > left untouched it resizes the window - which because the dialog is an iframe > means it resizes the main window. > > Minor changes to DateField.js to call my dialog component rather than > openWindow, along with an additional callback function for passing the > selected date back to the parent component. > > To Do: > Pass skinning keys to dialog javascript class so we can skin the dialog. > While it handles blocking clicks to parent, it doesn't handle keeping > keyboard nav inside the iframe. > > Your thoughts please... > > Danny > -- > Chordiant Software Inc. > www.chordiant.com > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
-- Chordiant Software Inc. www.chordiant.com
