I just commented out the offending entries in my pom.xml files and all seems well now.
On 1/31/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
Adam, Thanks for the cleanup, it was on my list, but I wanted feedback before progressing. I've pulled down the sandbox containing the changes, but it fails to build. The plugins are OK, but main trinidad tree fails. Suggestions welcome. [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:maven -jar-plugin:2.0 Cause: Cannot find setter nor field in org.apache.maven.archiver.ManifestConfigu ration for 'addDefaultSpecificationEntries' Agreed there's plenty to do, but now it's in the sandbox it's easier. Thanks, 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
-- Chordiant Software Inc. www.chordiant.com
