You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Danny Robinson <da...@gmail.com> on 2007/01/30 20:21:58 UTC
Early Prototype - Dialog using DHTML / iFrame
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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by venkata guddanti <ve...@gmail.com>.
Hi Danny,
If you do not have a mac and want to do some basic testing of Safari, you
can try Swift. Swift is kind of like a Windows version of the Safari. Here
is a link: http://try.swift.ws/
Please keep in mind that it is a beta product and has a lot of issues :).
Regards,
Venkata
On 2/7/07, Danny Robinson <da...@gmail.com> wrote:
>
> Thanks Adam.
>
> I'm surprised it works at all on Safari, I don't have a Mac I can test on!
> So that's good news, even if it does need a tweak.
>
> I'll take a look at the overlap you mentioned.
>
> One the size issue, I looked (in firefox) at launchDialog.jspx and noticed
> that it still uses the windowWidth & windowHeight attributes, which if you
> remove should resize to the content (at least it does for me). If you
> leave
> them in, then they just need to be increased.
>
> Danny
>
> On 2/7/07, Adam Winer <aw...@gmail.com> wrote:
> >
> > FWIW, a couple things I've noticed:
> > - On Safari, the popups have no border or background; in the
> > launchDialog.jspx demo, when you have two popups up together,
> > the title for one popup actually
> > overlaps the next (are they both being placed at the
> > same z-order?)
> > - The sizing algorithm doesn't seem to work that well - everything
> > is a bit too small (Safari + Firefox).
> >
> > -- Adam
> >
> >
> > On 2/6/07, Adam Winer <aw...@gmail.com> wrote:
> > > Committed this patch - thanks!
> > >
> > > -- Adam
> > >
> > >
> > > On 2/6/07, Danny Robinson <da...@gmail.com> wrote:
> > > > OK, just uploaded an updated patch.
> > > >
> > > > Dialogs will now appear at a fixed size if specified, or will resize
> > to that
> > > > of the first dialog page and remain that size for all other pages.
> > > > Started work on also removing frame redirect from date picker also.
> > > >
> > > > Danny.
> > > >
> > > >
> > > >
> > > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > > >
> > > > > On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > uploaded patch to jira - including extra bits for setting the
> > dialog
> > > > > title
> > > > > > using BodyRenderer.
> > > > >
> > > > > Nice!
> > > > >
> > > > > > A few quick questions also:
> > > > > >
> > > > > > Could we add the popup config entry to the trinidad config file
> > rather
> > > > > than
> > > > > > web.xml and allow it to use a value binding - this way we can
> test
> > both
> > > > > from
> > > > > > the same test/demo app?
> > > > >
> > > > > We've generally stuck to using trinidad-config basically for
> things
> > > > > that are on the RequestContext, and I don't think this is
> > > > > going to end up there.
> > > > >
> > > > > For the purposes of this branch, it'd be OK if the function
> > > > > that tested if popups were supported had something really
> > > > > goofy like:
> > > > > facesContext.getViewRoot().getViewId().contains("Popup")
> > > > >
> > > > > ... which'd be useful enough for testing, which is what
> > > > > this branch is for.
> > > > >
> > > > >
> > > > > > Quick questions:
> > > > > > Should we use the height/width properties as the master setting
> > for the
> > > > > > dialog size, and only resize to content if they were not set? I
> > guess
> > > > > we
> > > > > > wouldn't want to auto-resize to content in every situation, or
> > would we
> > > > > want
> > > > > > to always initially set it.
> > > > >
> > > > > Perhaps you use height/width as a minimum setting, and grow if
> > they're
> > > > > not set. Or, height/width are an absolute rule.
> > > > >
> > > > > > If we use the BodyRenderer approach to also set the dialog size,
> > how do
> > > > > we
> > > > > > ensure it doesn't keep resizing if the dialog runs to many
> pages?
> > > > >
> > > > > You could just stash a JS flag on the popup object; once
> > > > > resized, flip the flag and stop resizing.
> > > > >
> > > > > > Also title will change as you move from page to page in dialog -
> I
> > guess
> > > > > > this is appropriate through.
> > > > >
> > > > > Yes, that's what you want.
> > > > >
> > > > > > We have a few more options for closing dialogs also as the
> > javascript
> > > > > > component could even close modals if you clicked-off the dialog
> -
> > in
> > > > > some
> > > > > > instances this could be useful.
> > > > >
> > > > > Indeed, could be very useful!
> > > > >
> > > > > -- Adam
> > > > >
> > > > > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > > >
> > > > > > > Danny,
> > > > > > >
> > > > > > > Could you attach that patch to
> > > > > > > http://issues.apache.org/jira/browse/ADFFACES-307?
> > > > > > > This is the more official way of doing things.
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > > >
> > > > > > > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > > > > 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
> > > > > > > >
> > > > > > > > Great!
> > > > > > > >
> > > > > > > > > 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?
> > > > > > > >
> > > > > > > > I was thinking we could rely on BodyRenderer; if we detect
> > > > > > > > when we're inside of a dialog (perhaps by looking at
> > > > > > > > pageFlowScope), and when we know that dialogs are configured
> > > > > > > > to use popups, fire Javascript in the <body>'s onload. If
> > > > > > > > they don't want to use our <body> renderer, then they don't
> > > > > > > > get this fun.
> > > > > > > >
> > > > > > > > BTW, always be very careful when getting a property off of
> > > > > "parent"...
> > > > > > > > Wrap it in try/catch, because if the parent is in a
> different
> > > > > > > > URL domain, you can get a security exception.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > - 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.
> > > > > > > >
> > > > > > > > Hrm, when I get a chance to merge it in, I'll have a look.
> > > > > > > >
> > > > > > > > -- Adam
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Danny
> > > > > > > > >
> > > > > > > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com>
> > 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 <da...@gmail.com>
> > 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 <ma...@apache.org>
> > 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 <
> > dannyjrobinson@gmail.com>
> > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Chordiant Software Inc.
> > > > www.chordiant.com
> > > >
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
Thanks Adam.
I'm surprised it works at all on Safari, I don't have a Mac I can test on!
So that's good news, even if it does need a tweak.
I'll take a look at the overlap you mentioned.
One the size issue, I looked (in firefox) at launchDialog.jspx and noticed
that it still uses the windowWidth & windowHeight attributes, which if you
remove should resize to the content (at least it does for me). If you leave
them in, then they just need to be increased.
Danny
On 2/7/07, Adam Winer <aw...@gmail.com> wrote:
>
> FWIW, a couple things I've noticed:
> - On Safari, the popups have no border or background; in the
> launchDialog.jspx demo, when you have two popups up together,
> the title for one popup actually
> overlaps the next (are they both being placed at the
> same z-order?)
> - The sizing algorithm doesn't seem to work that well - everything
> is a bit too small (Safari + Firefox).
>
> -- Adam
>
>
> On 2/6/07, Adam Winer <aw...@gmail.com> wrote:
> > Committed this patch - thanks!
> >
> > -- Adam
> >
> >
> > On 2/6/07, Danny Robinson <da...@gmail.com> wrote:
> > > OK, just uploaded an updated patch.
> > >
> > > Dialogs will now appear at a fixed size if specified, or will resize
> to that
> > > of the first dialog page and remain that size for all other pages.
> > > Started work on also removing frame redirect from date picker also.
> > >
> > > Danny.
> > >
> > >
> > >
> > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > >
> > > > On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > uploaded patch to jira - including extra bits for setting the
> dialog
> > > > title
> > > > > using BodyRenderer.
> > > >
> > > > Nice!
> > > >
> > > > > A few quick questions also:
> > > > >
> > > > > Could we add the popup config entry to the trinidad config file
> rather
> > > > than
> > > > > web.xml and allow it to use a value binding - this way we can test
> both
> > > > from
> > > > > the same test/demo app?
> > > >
> > > > We've generally stuck to using trinidad-config basically for things
> > > > that are on the RequestContext, and I don't think this is
> > > > going to end up there.
> > > >
> > > > For the purposes of this branch, it'd be OK if the function
> > > > that tested if popups were supported had something really
> > > > goofy like:
> > > > facesContext.getViewRoot().getViewId().contains("Popup")
> > > >
> > > > ... which'd be useful enough for testing, which is what
> > > > this branch is for.
> > > >
> > > >
> > > > > Quick questions:
> > > > > Should we use the height/width properties as the master setting
> for the
> > > > > dialog size, and only resize to content if they were not set? I
> guess
> > > > we
> > > > > wouldn't want to auto-resize to content in every situation, or
> would we
> > > > want
> > > > > to always initially set it.
> > > >
> > > > Perhaps you use height/width as a minimum setting, and grow if
> they're
> > > > not set. Or, height/width are an absolute rule.
> > > >
> > > > > If we use the BodyRenderer approach to also set the dialog size,
> how do
> > > > we
> > > > > ensure it doesn't keep resizing if the dialog runs to many pages?
> > > >
> > > > You could just stash a JS flag on the popup object; once
> > > > resized, flip the flag and stop resizing.
> > > >
> > > > > Also title will change as you move from page to page in dialog - I
> guess
> > > > > this is appropriate through.
> > > >
> > > > Yes, that's what you want.
> > > >
> > > > > We have a few more options for closing dialogs also as the
> javascript
> > > > > component could even close modals if you clicked-off the dialog -
> in
> > > > some
> > > > > instances this could be useful.
> > > >
> > > > Indeed, could be very useful!
> > > >
> > > > -- Adam
> > > >
> > > > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > >
> > > > > > Danny,
> > > > > >
> > > > > > Could you attach that patch to
> > > > > > http://issues.apache.org/jira/browse/ADFFACES-307?
> > > > > > This is the more official way of doing things.
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > > >
> > > > > > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > > > 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
> > > > > > >
> > > > > > > Great!
> > > > > > >
> > > > > > > > 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?
> > > > > > >
> > > > > > > I was thinking we could rely on BodyRenderer; if we detect
> > > > > > > when we're inside of a dialog (perhaps by looking at
> > > > > > > pageFlowScope), and when we know that dialogs are configured
> > > > > > > to use popups, fire Javascript in the <body>'s onload. If
> > > > > > > they don't want to use our <body> renderer, then they don't
> > > > > > > get this fun.
> > > > > > >
> > > > > > > BTW, always be very careful when getting a property off of
> > > > "parent"...
> > > > > > > Wrap it in try/catch, because if the parent is in a different
> > > > > > > URL domain, you can get a security exception.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > - 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.
> > > > > > >
> > > > > > > Hrm, when I get a chance to merge it in, I'll have a look.
> > > > > > >
> > > > > > > -- Adam
> > > > > > >
> > > > > > > >
> > > > > > > > Danny
> > > > > > > >
> > > > > > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com>
> 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 <da...@gmail.com>
> 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 <ma...@apache.org>
> 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 <
> dannyjrobinson@gmail.com>
> > > > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Chordiant Software Inc.
> > > www.chordiant.com
> > >
> >
>
--
Chordiant Software Inc.
www.chordiant.com
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
FWIW, a couple things I've noticed:
- On Safari, the popups have no border or background; in the
launchDialog.jspx demo, when you have two popups up together,
the title for one popup actually
overlaps the next (are they both being placed at the
same z-order?)
- The sizing algorithm doesn't seem to work that well - everything
is a bit too small (Safari + Firefox).
-- Adam
On 2/6/07, Adam Winer <aw...@gmail.com> wrote:
> Committed this patch - thanks!
>
> -- Adam
>
>
> On 2/6/07, Danny Robinson <da...@gmail.com> wrote:
> > OK, just uploaded an updated patch.
> >
> > Dialogs will now appear at a fixed size if specified, or will resize to that
> > of the first dialog page and remain that size for all other pages.
> > Started work on also removing frame redirect from date picker also.
> >
> > Danny.
> >
> >
> >
> > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> > > > uploaded patch to jira - including extra bits for setting the dialog
> > > title
> > > > using BodyRenderer.
> > >
> > > Nice!
> > >
> > > > A few quick questions also:
> > > >
> > > > Could we add the popup config entry to the trinidad config file rather
> > > than
> > > > web.xml and allow it to use a value binding - this way we can test both
> > > from
> > > > the same test/demo app?
> > >
> > > We've generally stuck to using trinidad-config basically for things
> > > that are on the RequestContext, and I don't think this is
> > > going to end up there.
> > >
> > > For the purposes of this branch, it'd be OK if the function
> > > that tested if popups were supported had something really
> > > goofy like:
> > > facesContext.getViewRoot().getViewId().contains("Popup")
> > >
> > > ... which'd be useful enough for testing, which is what
> > > this branch is for.
> > >
> > >
> > > > Quick questions:
> > > > Should we use the height/width properties as the master setting for the
> > > > dialog size, and only resize to content if they were not set? I guess
> > > we
> > > > wouldn't want to auto-resize to content in every situation, or would we
> > > want
> > > > to always initially set it.
> > >
> > > Perhaps you use height/width as a minimum setting, and grow if they're
> > > not set. Or, height/width are an absolute rule.
> > >
> > > > If we use the BodyRenderer approach to also set the dialog size, how do
> > > we
> > > > ensure it doesn't keep resizing if the dialog runs to many pages?
> > >
> > > You could just stash a JS flag on the popup object; once
> > > resized, flip the flag and stop resizing.
> > >
> > > > Also title will change as you move from page to page in dialog - I guess
> > > > this is appropriate through.
> > >
> > > Yes, that's what you want.
> > >
> > > > We have a few more options for closing dialogs also as the javascript
> > > > component could even close modals if you clicked-off the dialog - in
> > > some
> > > > instances this could be useful.
> > >
> > > Indeed, could be very useful!
> > >
> > > -- Adam
> > >
> > > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > > >
> > > > > Danny,
> > > > >
> > > > > Could you attach that patch to
> > > > > http://issues.apache.org/jira/browse/ADFFACES-307?
> > > > > This is the more official way of doing things.
> > > > >
> > > > > -- Adam
> > > > >
> > > > >
> > > > > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > > 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
> > > > > >
> > > > > > Great!
> > > > > >
> > > > > > > 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?
> > > > > >
> > > > > > I was thinking we could rely on BodyRenderer; if we detect
> > > > > > when we're inside of a dialog (perhaps by looking at
> > > > > > pageFlowScope), and when we know that dialogs are configured
> > > > > > to use popups, fire Javascript in the <body>'s onload. If
> > > > > > they don't want to use our <body> renderer, then they don't
> > > > > > get this fun.
> > > > > >
> > > > > > BTW, always be very careful when getting a property off of
> > > "parent"...
> > > > > > Wrap it in try/catch, because if the parent is in a different
> > > > > > URL domain, you can get a security exception.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > - 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.
> > > > > >
> > > > > > Hrm, when I get a chance to merge it in, I'll have a look.
> > > > > >
> > > > > > -- Adam
> > > > > >
> > > > > > >
> > > > > > > Danny
> > > > > > >
> > > > > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com>
> > > 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
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Chordiant Software Inc.
> > www.chordiant.com
> >
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
Committed this patch - thanks!
-- Adam
On 2/6/07, Danny Robinson <da...@gmail.com> wrote:
> OK, just uploaded an updated patch.
>
> Dialogs will now appear at a fixed size if specified, or will resize to that
> of the first dialog page and remain that size for all other pages.
> Started work on also removing frame redirect from date picker also.
>
> Danny.
>
>
>
> On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> >
> > On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> > > uploaded patch to jira - including extra bits for setting the dialog
> > title
> > > using BodyRenderer.
> >
> > Nice!
> >
> > > A few quick questions also:
> > >
> > > Could we add the popup config entry to the trinidad config file rather
> > than
> > > web.xml and allow it to use a value binding - this way we can test both
> > from
> > > the same test/demo app?
> >
> > We've generally stuck to using trinidad-config basically for things
> > that are on the RequestContext, and I don't think this is
> > going to end up there.
> >
> > For the purposes of this branch, it'd be OK if the function
> > that tested if popups were supported had something really
> > goofy like:
> > facesContext.getViewRoot().getViewId().contains("Popup")
> >
> > ... which'd be useful enough for testing, which is what
> > this branch is for.
> >
> >
> > > Quick questions:
> > > Should we use the height/width properties as the master setting for the
> > > dialog size, and only resize to content if they were not set? I guess
> > we
> > > wouldn't want to auto-resize to content in every situation, or would we
> > want
> > > to always initially set it.
> >
> > Perhaps you use height/width as a minimum setting, and grow if they're
> > not set. Or, height/width are an absolute rule.
> >
> > > If we use the BodyRenderer approach to also set the dialog size, how do
> > we
> > > ensure it doesn't keep resizing if the dialog runs to many pages?
> >
> > You could just stash a JS flag on the popup object; once
> > resized, flip the flag and stop resizing.
> >
> > > Also title will change as you move from page to page in dialog - I guess
> > > this is appropriate through.
> >
> > Yes, that's what you want.
> >
> > > We have a few more options for closing dialogs also as the javascript
> > > component could even close modals if you clicked-off the dialog - in
> > some
> > > instances this could be useful.
> >
> > Indeed, could be very useful!
> >
> > -- Adam
> >
> > > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > >
> > > > Danny,
> > > >
> > > > Could you attach that patch to
> > > > http://issues.apache.org/jira/browse/ADFFACES-307?
> > > > This is the more official way of doing things.
> > > >
> > > > -- Adam
> > > >
> > > >
> > > > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > > 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
> > > > >
> > > > > Great!
> > > > >
> > > > > > 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?
> > > > >
> > > > > I was thinking we could rely on BodyRenderer; if we detect
> > > > > when we're inside of a dialog (perhaps by looking at
> > > > > pageFlowScope), and when we know that dialogs are configured
> > > > > to use popups, fire Javascript in the <body>'s onload. If
> > > > > they don't want to use our <body> renderer, then they don't
> > > > > get this fun.
> > > > >
> > > > > BTW, always be very careful when getting a property off of
> > "parent"...
> > > > > Wrap it in try/catch, because if the parent is in a different
> > > > > URL domain, you can get a security exception.
> > > > >
> > > > >
> > > > > >
> > > > > > - 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.
> > > > >
> > > > > Hrm, when I get a chance to merge it in, I'll have a look.
> > > > >
> > > > > -- Adam
> > > > >
> > > > > >
> > > > > > Danny
> > > > > >
> > > > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com>
> > 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
> > >
> > >
> >
>
>
>
> --
> Chordiant Software Inc.
> www.chordiant.com
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
OK, just uploaded an updated patch.
Dialogs will now appear at a fixed size if specified, or will resize to that
of the first dialog page and remain that size for all other pages.
Started work on also removing frame redirect from date picker also.
Danny.
On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
>
> On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> > uploaded patch to jira - including extra bits for setting the dialog
> title
> > using BodyRenderer.
>
> Nice!
>
> > A few quick questions also:
> >
> > Could we add the popup config entry to the trinidad config file rather
> than
> > web.xml and allow it to use a value binding - this way we can test both
> from
> > the same test/demo app?
>
> We've generally stuck to using trinidad-config basically for things
> that are on the RequestContext, and I don't think this is
> going to end up there.
>
> For the purposes of this branch, it'd be OK if the function
> that tested if popups were supported had something really
> goofy like:
> facesContext.getViewRoot().getViewId().contains("Popup")
>
> ... which'd be useful enough for testing, which is what
> this branch is for.
>
>
> > Quick questions:
> > Should we use the height/width properties as the master setting for the
> > dialog size, and only resize to content if they were not set? I guess
> we
> > wouldn't want to auto-resize to content in every situation, or would we
> want
> > to always initially set it.
>
> Perhaps you use height/width as a minimum setting, and grow if they're
> not set. Or, height/width are an absolute rule.
>
> > If we use the BodyRenderer approach to also set the dialog size, how do
> we
> > ensure it doesn't keep resizing if the dialog runs to many pages?
>
> You could just stash a JS flag on the popup object; once
> resized, flip the flag and stop resizing.
>
> > Also title will change as you move from page to page in dialog - I guess
> > this is appropriate through.
>
> Yes, that's what you want.
>
> > We have a few more options for closing dialogs also as the javascript
> > component could even close modals if you clicked-off the dialog - in
> some
> > instances this could be useful.
>
> Indeed, could be very useful!
>
> -- Adam
>
> > On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > Danny,
> > >
> > > Could you attach that patch to
> > > http://issues.apache.org/jira/browse/ADFFACES-307?
> > > This is the more official way of doing things.
> > >
> > > -- Adam
> > >
> > >
> > > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > > 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
> > > >
> > > > Great!
> > > >
> > > > > 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?
> > > >
> > > > I was thinking we could rely on BodyRenderer; if we detect
> > > > when we're inside of a dialog (perhaps by looking at
> > > > pageFlowScope), and when we know that dialogs are configured
> > > > to use popups, fire Javascript in the <body>'s onload. If
> > > > they don't want to use our <body> renderer, then they don't
> > > > get this fun.
> > > >
> > > > BTW, always be very careful when getting a property off of
> "parent"...
> > > > Wrap it in try/catch, because if the parent is in a different
> > > > URL domain, you can get a security exception.
> > > >
> > > >
> > > > >
> > > > > - 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.
> > > >
> > > > Hrm, when I get a chance to merge it in, I'll have a look.
> > > >
> > > > -- Adam
> > > >
> > > > >
> > > > > Danny
> > > > >
> > > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com>
> 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
> >
> >
>
--
Chordiant Software Inc.
www.chordiant.com
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
On 2/3/07, Danny Robinson <da...@gmail.com> wrote:
> uploaded patch to jira - including extra bits for setting the dialog title
> using BodyRenderer.
Nice!
> A few quick questions also:
>
> Could we add the popup config entry to the trinidad config file rather than
> web.xml and allow it to use a value binding - this way we can test both from
> the same test/demo app?
We've generally stuck to using trinidad-config basically for things
that are on the RequestContext, and I don't think this is
going to end up there.
For the purposes of this branch, it'd be OK if the function
that tested if popups were supported had something really
goofy like:
facesContext.getViewRoot().getViewId().contains("Popup")
... which'd be useful enough for testing, which is what
this branch is for.
> Quick questions:
> Should we use the height/width properties as the master setting for the
> dialog size, and only resize to content if they were not set? I guess we
> wouldn't want to auto-resize to content in every situation, or would we want
> to always initially set it.
Perhaps you use height/width as a minimum setting, and grow if they're
not set. Or, height/width are an absolute rule.
> If we use the BodyRenderer approach to also set the dialog size, how do we
> ensure it doesn't keep resizing if the dialog runs to many pages?
You could just stash a JS flag on the popup object; once
resized, flip the flag and stop resizing.
> Also title will change as you move from page to page in dialog - I guess
> this is appropriate through.
Yes, that's what you want.
> We have a few more options for closing dialogs also as the javascript
> component could even close modals if you clicked-off the dialog - in some
> instances this could be useful.
Indeed, could be very useful!
-- Adam
> On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
> >
> > Danny,
> >
> > Could you attach that patch to
> > http://issues.apache.org/jira/browse/ADFFACES-307?
> > This is the more official way of doing things.
> >
> > -- Adam
> >
> >
> > On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > > 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
> > >
> > > Great!
> > >
> > > > 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?
> > >
> > > I was thinking we could rely on BodyRenderer; if we detect
> > > when we're inside of a dialog (perhaps by looking at
> > > pageFlowScope), and when we know that dialogs are configured
> > > to use popups, fire Javascript in the <body>'s onload. If
> > > they don't want to use our <body> renderer, then they don't
> > > get this fun.
> > >
> > > BTW, always be very careful when getting a property off of "parent"...
> > > Wrap it in try/catch, because if the parent is in a different
> > > URL domain, you can get a security exception.
> > >
> > >
> > > >
> > > > - 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.
> > >
> > > Hrm, when I get a chance to merge it in, I'll have a look.
> > >
> > > -- Adam
> > >
> > > >
> > > > Danny
> > > >
> > > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
>
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
uploaded patch to jira - including extra bits for setting the dialog title
using BodyRenderer.
A few quick questions also:
Could we add the popup config entry to the trinidad config file rather than
web.xml and allow it to use a value binding - this way we can test both from
the same test/demo app?
Quick questions:
Should we use the height/width properties as the master setting for the
dialog size, and only resize to content if they were not set? I guess we
wouldn't want to auto-resize to content in every situation, or would we want
to always initially set it.
If we use the BodyRenderer approach to also set the dialog size, how do we
ensure it doesn't keep resizing if the dialog runs to many pages?
Also title will change as you move from page to page in dialog - I guess
this is appropriate through.
We have a few more options for closing dialogs also as the javascript
component could even close modals if you clicked-off the dialog - in some
instances this could be useful.
Cheers,
Danny
On 2/3/07, Adam Winer <aw...@gmail.com> wrote:
>
> Danny,
>
> Could you attach that patch to
> http://issues.apache.org/jira/browse/ADFFACES-307?
> This is the more official way of doing things.
>
> -- Adam
>
>
> On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> > On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > > 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
> >
> > Great!
> >
> > > 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?
> >
> > I was thinking we could rely on BodyRenderer; if we detect
> > when we're inside of a dialog (perhaps by looking at
> > pageFlowScope), and when we know that dialogs are configured
> > to use popups, fire Javascript in the <body>'s onload. If
> > they don't want to use our <body> renderer, then they don't
> > get this fun.
> >
> > BTW, always be very careful when getting a property off of "parent"...
> > Wrap it in try/catch, because if the parent is in a different
> > URL domain, you can get a security exception.
> >
> >
> > >
> > > - 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.
> >
> > Hrm, when I get a chance to merge it in, I'll have a look.
> >
> > -- Adam
> >
> > >
> > > Danny
> > >
> > > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
Danny,
Could you attach that patch to
http://issues.apache.org/jira/browse/ADFFACES-307?
This is the more official way of doing things.
-- Adam
On 2/2/07, Adam Winer <aw...@gmail.com> wrote:
> On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> > 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
>
> Great!
>
> > 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?
>
> I was thinking we could rely on BodyRenderer; if we detect
> when we're inside of a dialog (perhaps by looking at
> pageFlowScope), and when we know that dialogs are configured
> to use popups, fire Javascript in the <body>'s onload. If
> they don't want to use our <body> renderer, then they don't
> get this fun.
>
> BTW, always be very careful when getting a property off of "parent"...
> Wrap it in try/catch, because if the parent is in a different
> URL domain, you can get a security exception.
>
>
> >
> > - 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.
>
> Hrm, when I get a chance to merge it in, I'll have a look.
>
> -- Adam
>
> >
> > Danny
> >
> > On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
> >
> >
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
On 2/2/07, Danny Robinson <da...@gmail.com> wrote:
> 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
Great!
> 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?
I was thinking we could rely on BodyRenderer; if we detect
when we're inside of a dialog (perhaps by looking at
pageFlowScope), and when we know that dialogs are configured
to use popups, fire Javascript in the <body>'s onload. If
they don't want to use our <body> renderer, then they don't
get this fun.
BTW, always be very careful when getting a property off of "parent"...
Wrap it in try/catch, because if the parent is in a different
URL domain, you can get a security exception.
>
> - 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.
Hrm, when I get a chance to merge it in, I'll have a look.
-- Adam
>
> Danny
>
> On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
>
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
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 <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Matthias Wessendorf <ma...@apache.org>.
Thanks!
the CLA is already available on file
(Daniel Robinson)
http://people.apache.org/~jim/committers.html
-Matthias
On 1/31/07, Adam Winer <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
I just commented out the offending entries in my pom.xml files and all seems
well now.
On 1/31/07, Danny Robinson <da...@gmail.com> 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 <aw...@gmail.com> 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 <da...@gmail.com> 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 < dannyjrobinson@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
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 <aw...@gmail.com> 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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Adam Winer <aw...@gmail.com>.
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 <da...@gmail.com> 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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
>
>
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
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 <da...@gmail.com> 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 <ma...@apache.org> 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 < dannyjrobinson@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Matthias Wessendorf <ma...@apache.org>.
taking no 3rd party js lib is welcome.
To me it doesn't make sense to use a huge lib for "just one widget"
-Matthias
On 1/31/07, Danny Robinson <da...@gmail.com> 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 <ma...@apache.org> 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 <da...@gmail.com> 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
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Danny Robinson <da...@gmail.com>.
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 <ma...@apache.org> 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 <da...@gmail.com> 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
Re: Early Prototype - Dialog using DHTML / iFrame
Posted by Matthias Wessendorf <ma...@apache.org>.
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 <da...@gmail.com> 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