You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by JS Portal Support <su...@jsportal.com> on 2007/05/03 03:43:13 UTC

AJAX and shale (sub)dialog

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?

Regards,
Joost


RE: AJAX and shale (sub)dialog

Posted by JS Portal Support <su...@jsportal.com>.
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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 <su...@jsportal.com> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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 <su...@jsportal.com> 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

Posted by Craig McClanahan <cr...@apache.org>.
On 5/2/07, JS Portal Support <su...@jsportal.com> 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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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 <su...@jsportal.com> 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

Posted by JS Portal Support <su...@jsportal.com>.
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: craigmcc@gmail.com [mailto:craigmcc@gmail.com] 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 <su...@jsportal.com> 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

Posted by Craig McClanahan <cr...@apache.org>.
On 5/2/07, JS Portal Support <su...@jsportal.com> 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
>
>