Aaron, I have similar requirements. I have managed to get something working by using JSP to render my portlet fragments, and getting the JSP to include specific JavaScript functions in the portlet fragments (to do the XMLHttpRequest interaction). In addition, I include a special .js file in all of my rendered portal pages, so that I get common JavaScript functions that are required to allow AJAX communications to work at all.
It's all a right royal PITA, especially as having two instances of the same portlet in the same page can cause JavaScript errors (e.g. the same JavaScript function being defined twice) If, like me, you are very careful, you can avoid this. My requirements come from the need to get a portlet to update its own contents periodically, without refreshing the whole portal page. The contents come from a servlet on another server, and I use AJAX to retrieve the content. Mike Church Software Engineering QinetiQ Bldg Lovell Rm 109 Malvern Technology Centre St. Andrews Road, Malvern Worcestershire, WR14 3PS Tel: 01684 896085 Email: [EMAIL PROTECTED] Web: www.QinetiQ.com QinetiQ - The Global Defence and Security Experts > -----Original Message----- > From: Aaron Evans [mailto:[EMAIL PROTECTED] > Sent: 23 March 2006 18:30 > To: [email protected] > Subject: J2 and AJAX > > I have seen some discussions floating about lately regarding AJAX and > J2 and I have also checked out the documentation at: > > http://portals.apache.org/jetspeed-2/guides/guide-ajax-api.html > > However, my specific use case falls outside of portal/portlet > administration. What I am looking to do is to use AJAX to fetch data > in XML format from a service within my application to include on the > fly within portlet content for a variety of purposes. > > I am wondering if the AJAX capabilities of J2 can assist with this. > At the moment, I believe the answer is more or less no (unless the XML > comes from the output of a portlet rendering). > > At this point, my approach will be to use a servlet within my > application and by-pass the the portal. The servlet (or some part of > the webapp outside of the realm of portlets) will then have to manage > security for the requests for the data. This should be simple enough > by using SSO. And this is all fine, I really don't mind doing it this > way. > > However, I feel that it would be very useful to be able to provide > access to such a service through the portal (ie via the Ajax API) and > be able to use the same kind of security constraints that are commonly > placed on pages and fragments (plus then SSO wouldn't be required). > > My service exists only to provide data to UI interfaces rendered by > portlets. Thus, defining a portlet to deliver it via the rendering of > XML content and then placing it in a hidden PSML page for that sole > purpose seems like overkill. > > Perhaps there exists a simple way to accomplish this through Jetspeed > that I am unaware of. Otherwise, I suppose I am leaving this as more > of a suggestion perhaps for future functionality. If there are others > that have similar requirements, then it may be worth creating a JIRA > entry... > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). The information in this communication may be confidential and/or legally privileged. Nothing in this e-mail is intended to conclude a contract on behalf of QinetiQ or make QinetiQ subject to any other legally binding commitments, unless the e-mail contains an express statement to the contrary or incorporates a formal Purchase Order. For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored and recorded for business purposes including security, audit and archival purposes. Any response to this email indicates consent to this. Telephone calls to QinetiQ may be monitored or recorded for quality control, security and other business purposes. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
