Thanks! the CLA is already available on file (Daniel Robinson)
http://people.apache.org/~jim/committers.html -Matthias 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 > >
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
