shale-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JS Portal Support" <>
Subject RE: AJAX and shale (sub)dialog
Date Sun, 06 May 2007 01:17:32 GMT

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.

-----Original Message-----
From: [] On Behalf Of Craig
Sent: Thursday, May 03, 2007 2:46 PM
Subject: Re: AJAX and shale (sub)dialog

On 5/2/07, JS Portal Support <> 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.


> Thanks,
> Joost
> -----Original Message-----
> From: [] On Behalf Of Craig
> McClanahan
> Sent: Thursday, May 03, 2007 1:52 PM
> To:
> Subject: Re: AJAX and shale (sub)dialog
> On 5/2/07, JS Portal Support <> wrote:
> > Hi,
> >
> > What I have is a floating dojo ContentPane (popup) that loads its
> > 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.
> > 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
> > 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]
> > Regards,
> > Joost
> >
> >

View raw message