RE: AJAX and shale (sub)dialog
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
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
RE: AJAX and shale (sub)dialog
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? 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
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
