I take it back. I have no idea why it doen't work as I expected it to. -----Ursprüngliche Nachricht----- Von: Adam Winer [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 16:19 An: [email protected] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von > Craig McClanahan > Gesendet: Montag, 29. Januar 2007 22:44 > An: [email protected] > Betreff: Re: Shale and dialog framework > > On 1/29/07, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > > On 29-Jan-07, at 2:21 PM, Craig McClanahan wrote: > > > On 1/29/07, Meyer, Stefan <[EMAIL PROTECTED]> 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 > > > > > > > > >
