incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Robinson" <dannyjrobin...@gmail.com>
Subject Re: Early Prototype - Dialog using DHTML / iFrame
Date Sat, 03 Feb 2007 20:39:22 GMT
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 <awiner@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 <awiner@gmail.com> wrote:
> > On 2/2/07, Danny Robinson <dannyjrobinson@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 <awiner@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 <dannyjrobinson@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 <matzew@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message