incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: AW: Shale and dialog framework
Date Wed, 31 Jan 2007 17:00:34 GMT
>From: "Meyer, Stefan" <S.Meyer@S2neueinformatik.de> 
>
> I take it back. I have no idea why it doen't work as I expected it to. 
>

Ya I agree, that's some voodoo going on there :--)  Kind of like reading the CliffsNotes 
to find all the hidden meaning.

 
> -----Ursprüngliche Nachricht----- 
> Von: Adam Winer [mailto:awiner@gmail.com] 
> Gesendet: Dienstag, 30. Januar 2007 16:19 
> An: adffaces-user@incubator.apache.org 
> Betreff: Re: Shale and dialog framework 
> 
> 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 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 wrote: 
> > > 
> > > On 29-Jan-07, at 2:21 PM, Craig McClanahan wrote: 
> > > > On 1/29/07, Meyer, Stefan 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: 
> > > > 
> > > > 
> > > > 
> > > > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message