Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-).
I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup().setTitle( document.title);) which works for me. Thoughts? - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope. Anyway - it works in my own little web app using the add number demo and date picker. Danny On 1/31/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Danny, I grabbed the patch, made a branch, and applied it. I fixed up some things: - Moved (almost) all of the popup dialog and panel popup JS code into TrPanelPopup and TrPopupDialog wrapper objects - Fix coding convention problems: no tabs allowed, braces on new lines - Instead of removing the code that launched new windows for dialogs, hide it behind a web.xml context init parameter (currently defaulting to the old style) - Use resource bundle for translatable contents - Load JS automatically There's plenty to do still, most importantly: - Implement sizing correctly - Populate title of the popup based on the title of the dialog's content - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME But, that said: cool stuff! I think before we could look at merging anything into trunk, we'd need an Apache licensing agreement signed off on (because it's a non-trivial chunk of code...) -- Adam On 1/30/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > Patch file available here: http://thefoxberry.com/ > > Only note, is that this also contains the panelPopup component, and that > you'll need to include the two .js files into the servlet that merges the > common javascript. If I get chance later, I'll do this and repost the > patch. > > Should work fine in Firefox or IE, others are untested. > > Danny > > On 1/30/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > -- > Chordiant Software Inc. > www.chordiant.com > >
-- Chordiant Software Inc. www.chordiant.com
