incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Shale and dialog framework
Date Tue, 30 Jan 2007 15:18:33 GMT
Not exactly....  the behavior's a bit more complicated than that.
There's not two simultaneous calls, but there are calls
to the original page that may not be obvious.

Here's how it goes. in all the gory detail:

In browser: User clicks on a commandButton

Request 1:
Postback handling:
- ActionEvent is broadcast, and NavigationHandlerImpl notes it
  begins with "dialog:"
- Instead of navigating to that UIViewRoot, a LaunchEvent is queued
  with the target UIViewRoot
- UIXCommand component receives the launch event, and
  asks the RequestContext to launch a dialog.
- The RequestContext asks the RenderKit if it supports launching
   dialogs, and if so, tells it to launch a dialog on this request.

Rendering:
- A bit of Javascript is rendered that will launch a popup.  (Not
  during onload, per se, just inline).  The JS points not directly
  at the target view ID, but at an intermediate frameset that
  will in turn launch the target view ID (but this implementation
  strategy is encapsulated inside of the RK)


Back on the browser, a new window pops up with the
correct URL.

Request 2:
Rendering only:
- An URL comes in requesting the frameset rendering
- It's intercepted by our ViewHandler, which recognizes
  that the viewId is that of a registered "InternalView" - another
  public extensible API in Trinidad - and therefore is handled
  without going to any JSPs

Request 3:
Rendering only:
- The dialog's viewId finally loads

....

User clicks a commandButton (for example, could be anything) in a page

Request N-1:
Postback:
- Action listener calls RequestContext.returnFromDialog()
- RenderKit is again involved
Rendering:
- Javascript is rendered to return from the dialog, by
  submitting the original window

Back on the browser, the original window receives
a form submission while the popup window closes.

Request N:
Postback:
- The original commandButton's Renderer detects
  a ReturnEvent, and queues it
- A returnListener does whatever it wants to

And that's all there is to it. ;)  Well, actually, it's more complicated
than that, because this rendering generally all happens with
partial-page rendering, so nothing flashes on the original page
as this happens, and new pageFlowScopes are being created,
populated, and destroyed.

I'd love to see this hooked up to a popup system (probably
by using a DHTML popup containing an IFRAME pointing
at the target URL).  That could happen without any public
API changes or modification of user's JSP or Facelets
pages.

-- Adam



On 1/30/07, Meyer, Stefan <S.Meyer@s2neueinformatik.de> wrote:
> The issue is pretty obvious. The Dialog framework launches a popup in the onload js event,
if the outcome / action starts with the "dialog:" keyword and the action was launched by a
commandButton/commandLink with the useWindow attribute set to true. Basically the dialog framework
renders two views in two separate windows at once. The outcome specifies the view to display
in the popup window while the orignial view is left unchanged. Therefore shale calls the lifecycle
methods in both requests on the same viewController. That Viewcontroller should only handle
the popup view though.
>
> Stefan
>
> -----Urspr√ľngliche Nachricht-----
> Von: craigmcc@gmail.com [mailto:craigmcc@gmail.com] Im Auftrag von Craig McClanahan
> Gesendet: Montag, 29. Januar 2007 22:44
> An: adffaces-user@incubator.apache.org
> Betreff: Re: Shale and dialog framework
>
> On 1/29/07, Laurie Harper <laurie@holoweb.net> wrote:
> >
> > On 29-Jan-07, at 2:21 PM, Craig McClanahan wrote:
> > > On 1/29/07, Meyer, Stefan <S.Meyer@s2neueinformatik.de> wrote:
> > >> The Viewcontroller does not work well with the dialog framework,
> > >> because the lifecycle methods are called on the popup view bean for
> > >> the parent and child request and not at all for the launching view.
> > >> Fixing this would maybe mean, that the action outcome cannot define
> > >> the view to present in the popup.
> > >
> > > Stefan,
> > >
> > > I am not sure I quite get what you mean here.
> > >
> > > My assumption, when you are using a popup, is that you'll be using
> > > client side JavaScript to actually create the popup.  Here's a
> > > snippet of code from our "shale-test-dialog-basic" and
> > > "shale-test-dialog-scxml" test applications that does it:
> > >
> > >    <a href="#" onclick="javascript:window.open('menu.faces
> > > ','popup','height=600,width=400')"/>
> > >
> > > Note that this does *not* send back a request for the calling view
> > > (the page in which the JavaScript above was embedded), so there is
> > > no reason to invoke any callback methods for it.  This request will
> > > open a new window, and the callbacks for the "menu.faces" page will
> > > be called as expected.
> > >
> > > What part of this behavior is not working for you?
> > >
> > > Craig
> >
> > I think the OP is talking about how Shale's View Controller
> > functionality interacts with Trinidad's dialog framework, which relies
> > on PPR and has a somewhat more involved request/response structure.
>
>
> Well, that would make sense given this is on the Trinidad list ... gotta check the mail
headers before I make assumptions :-).
>
>
> Stefan, I'd suggest putting together a minimal test application that
> > demonstrates the problem and posting it as a WAR file in JIRA. A
> > possibly unintended interaction between features from two different
> > frameworks will be tough to diagnose without a testcase.
>
>
> That would definitely be helpful.
>
> Craig
>
> L.
> > --
> > Laurie Harper
> > Open Source advocate, Java geek: http://www.holoweb.net/laurie
> >
> >
> >
> >
>

Mime
View raw message