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
