shale-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JS Portal Support" <supp...@jsportal.com>
Subject RE: AJAX and shale (sub)dialog
Date Sun, 06 May 2007 01:17:32 GMT
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 <support@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 <support@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
> >
> >
>
>



Mime
View raw message