>From: "Meyer, Stefan" <[EMAIL PROTECTED]> > > 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:[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 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 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 > > > > > > > > > > > > > >
