Craig, I got everything to work like I would want it to with an IFRAME (the shale-test-dialog-basic was very helpful). I was wondering however if it is possible to have a subdialog on top of the regular jsf navigation-rules, so that the jsf state will not be changed when a dialog is run on top of it though my IFRAME. The other option is obviously to change completely to dialog navigation.
Thanks, Joost -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, May 03, 2007 2:46 PM To: user@shale.apache.org Subject: Re: AJAX and shale (sub)dialog On 5/2/07, JS Portal Support <[EMAIL PROTECTED]> wrote: > Craig, > > First off, thanks for your elaborate explanation. I believe I'm slowly > starting to get a better grasp of all subtleties involved. Remoting seems > great for a situation where only one call to the server needs to be made > without state saving. > > - Is it possible to make a remoting call to a regular *.jsf page which may > contain commandLink's and other jsf components? > > As for the ContentPane I must apologize as by popup I did not mean a new > window, but a floating div acting as a dojo ContentPane (see attachement). > > - In this situation, is it possible to start a subdialog from the floating > ConetntPane without affecting the underlying page? > The mailing list blocks most attachments, so I didn't see what you attached ... but Shale Dialogs has two restrictions to be aware of: * Only one active dialog per window or frame. If the Dojo ContentPane used an IFrame, this might not be a problem, but if it is just a <div> that is getting dynamically updated, then this won't work. * Shale Dialog assumes that the popup UI is actually composed with JSF components. Since that is not the case here, it seems like Remoting might be a better solution. Craig > Thanks, > Joost > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig > McClanahan > Sent: Thursday, May 03, 2007 1:52 PM > To: user@shale.apache.org > Subject: Re: AJAX and shale (sub)dialog > > On 5/2/07, JS Portal Support <[EMAIL PROTECTED]> wrote: > > Hi, > > > > What I have is a floating dojo ContentPane (popup) that loads its content > > though AJAX. > > > > What I wish to achieve is for this ContentPane to handle multiple > > requests/responses without interfering with the underlying view state of > the > > actual non-AJAX jsf page. > > > > From what I understand JSF can solve this by using a phaseListner, but > > shale's (sub)dialog seems to be stronger and better suited for the job. As > > I'm new to this area I might be off and wrong here. > > > > Before I start coding away and solve the problems I run into, I would love > > to see some examples or documentation laying out how this can be done > > elegantly. Can anyone point me in the right direction? > > > > The dialog support will work nicely for you if you want the content of > the popup to itself be composed with JSF components. Because the > popup is an independent window, it has its own component tree > independent of the main page, and goes through its own lifecycle > separately. The dialog system even knows how to have separate dialogs > in progress in each window without getting confused. There are > samples of how to start such popups in the shale-test-dialog-basic and > shale-test-dialog-scxml sample apps. > > In your case, however, it sounds like you want to let Dojo deal with > the UI in the popup, and just need a way to provide the back end > services for the Ajax callbacks. For that use case, I would also take > a look at using Shale Remoting for the callbacks. Among other things, > this will let you map a request URL (originated by an XMLHttpRequest > from the client) directly to a public method on a particular managed > bean. These requests do not have a component tree of their own (and > they don't affect the component tree for the main view). The point > here is to let you leverage the non-UI server side features of JSF > (particularly managed beans and EL evaluation) for Ajax callbacks. > > Besides the documentation on the Shale Remoting page itself, this > technique was used inside the Autocomplete Text Field component in the > Blueprints Catalog[1], which can serve as a pretty good coding example > for use within an application as well. > > Craig > > [1] https://bpcatalog.dev.java.net/ > > > > Regards, > > Joost > > > > > >
