J2 and AJAX

[aaronmevans]

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: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[Church Michael R]

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:    [phone]
Email:  mrchurch@...
Web:    www.QinetiQ.com

QinetiQ - The Global Defence and Security Experts

> -----Original Message-----
> From: Aaron Evans [mailto:aaronmevans@...]
> Sent: 23 March 2006 18:30
> To: jetspeed-user@...
> 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: jetspeed-user-unsubscribe@...
> For additional commands, e-mail: jetspeed-user-help@...

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: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[David Sean Taylor]

Aaron Evans wrote:

> 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).
>

The Jetspeed AJAX API is an API for controlling Jetspeed with AJAX

The MVC framework of actions and views that implements the server side
of the Jetspeed Ajax API could easily be used in your portlet app
without too much effort. Just remember to secure access to the actions

If you look at Jetspeed Desktop we are are retrieving portlet context
over the portlet pipeline. Javascript is controlling the rendering, and
making a request over the portlet pipeline. (This is still very much
under development. Please dont log bugs against this feature!)

you can view the Jetspeed Desktop on any page in the system
Replace /jetspeed/portal with /jetspeed/desktop

> 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.

Yup, I've done the same thing, but I did re-use the Jetspeed Action
API's little MVC framework because, well it works very well.
The part I do not like about this approach is static security defs in
the web.xml. Prefer to use Jetspeed's security permissions to handle
this by extending the JetspeedPermission class with a new
ActionActionPermission.

>
> 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).
>
I should probably read all the paragraphs before responding :)
I think its a good idea. Then we dont have to build infrastructure into
our portlet applications, write a new servlet, etc..
If Jetspeed could be the secure gate keeper, and then delegate to
'actions' in portlet apps to do the actions, I think that would be a
better solution than one servlet controller per portlet app

> 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.

Yup, I agree

>
> 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...
>

What do you think about a new feature where Jetspeed can execute secured
ajax actions in portlet applications. The actions would just be POJOs
like in the Jetspeed AJAX API, and we could secure the actions in the
security policy

--
David Sean Taylor
Bluesunrise Software
david@...
[office] +01 707 773-4646
[mobile] +01 707 529 9194

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[David Sean Taylor]

Church Michael R wrote:

> 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
>

Interesting.
I've been using both Dojo and Backbase(commercial) in my portlets.
Haven't had many problems related to running javascript libraries in
portlets, but maybe because we write all the portlets in our particular
apps, so we have complete control. Just need to include the script
imports in the layout header. Randy is doing some work (and the JSR 286
team) to better formalize this.

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[aaronmevans]

On 3/23/06, David Sean Taylor <david@...> wrote:
>
> What do you think about a new feature where Jetspeed can execute secured
> ajax actions in portlet applications. The actions would just be POJOs
> like in the Jetspeed AJAX API, and we could secure the actions in the
> security policy
>

Yes, that sounds like a dandy idea.  But it might be nice if the
actions were actually implementations of some simple interface whose
'doAction' method or whatever had access to the request and response.

For my particular use case, I'm not just triggering server side
business logic, I'm also writing XML to the response.  And actually,
if you could control the response headers and write to the response,
that would also solve the download of arbitrary binary data problem.

Of course it would be sweet if there were something in the
portal/portlet spec that we could leverage here (and not be so
proprietary), but I just don't think there is anything that fits the
bill...

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[David Sean Taylor]

Aaron Evans wrote:

> On 3/23/06, David Sean Taylor <david@...> wrote:
>
>>What do you think about a new feature where Jetspeed can execute secured
>>ajax actions in portlet applications. The actions would just be POJOs
>>like in the Jetspeed AJAX API, and we could secure the actions in the
>>security policy
>>
>
>
> Yes, that sounds like a dandy idea.  But it might be nice if the
> actions were actually implementations of some simple interface whose
> 'doAction' method or whatever had access to the request and response.
>

Take a look at the interfaces here in the Jetspeed API:

http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/org/apache/jetspeed/ajax/package-summary.html

There are actually two Ajax upshoots in Jetspeed right (three if you
count the desktop work). The two in this directory are non-compatible.
The one I use depends on the RequestContext, since its very much a
Jetspeed type API. We need to access a lot of Jetspeed components in our
  Jetspeed actions.

The actions 'could' be dynamically found (there is already code to do
that in the first ajax impl). As long as the actions are secured, this
might be a good solution. Pretty cool. In the past I've tried to
abstract the Java class names from the Javascript programmer, so they
could simply be called by an action name. I prefer this method as its
easier for me when coding on the client side, and seems more secure.
Perhaps a runtime registration of actions might work, and associate the
action with a portlet application so we can get the class loader hooked
up correctly.

Im also thinking the actions could be methods on portlets.
I guess Im still in the 'thinking' stage here, thinking out loud on a
public mailing list...

> For my particular use case, I'm not just triggering server side
> business logic, I'm also writing XML to the response.  And actually,
> if you could control the response headers and write to the response,
> that would also solve the download of arbitrary binary data problem.
>

Almost sounds to me like you want a portlet that acts upon an xml
content type. Calling the portlet pipeline, no?

The challenge there is having the Javascript send parameters to the
portlet. Perhaps the portlet pipeline should take the servlet request
parameters, if on a portlet pipeline, and send them on to the portlet as
portlet render parameters.

This sounds interesting

> Of course it would be sweet if there were something in the
> portal/portlet spec that we could leverage here (and not be so
> proprietary), but I just don't think there is anything that fits the
> bill...
>
The portlet spec team just started discussing this
Unfortunately Im a few weeks behind on my emails there :(


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[aaronmevans]

On 3/23/06, David Sean Taylor <david@...> wrote:
> Aaron Evans wrote:
> > On 3/23/06, David Sean Taylor <david@...> wrote:
> >
> >>What do you think about a new feature where Jetspeed can execute secured
> >>ajax actions in portlet applications. The actions would just be POJOs
> >>like in the Jetspeed AJAX API, and we could secure the actions in the
> >>security policy
> >>
> >
ets> >
> > Yes, that sounds like a dandy idea.  But it might be nice if the
> > actions were actually implementations of some simple interface whose
> > 'doAction' method or whatever had access to the request and response.
> >
> Take a look at the interfaces here in the Jetspeed API:
>
> http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/org/apache/jetspeed/ajax/package-summary.html
>

I had a look.  The AJAXService says it "Performs invocation of the
actual AJAX request and returns a result object to converted into
XML.". It is unclear to me how one controls what the resulting XML
would look like.

> There are actually two Ajax upshoots in Jetspeed right (three if you
> count the desktop work). The two in this directory are non-compatible.
> The one I use depends on the RequestContext, since its very much a
> Jetspeed type API. We need to access a lot of Jetspeed components in our
>   Jetspeed actions.
>
> The actions 'could' be dynamically found (there is already code to do
> that in the first ajax impl). As long as the actions are secured, this
> might be a good solution. Pretty cool. In the past I've tried to
> abstract the Java class names from the Javascript programmer, so they
> could simply be called by an action name. I prefer this method as its
> easier for me when coding on the client side, and seems more secure.
> Perhaps a runtime registration of actions might work, and associate the
> action with a portlet application so we can get the class loader hooked
> up correctly.

Yes, I agree.  Java class names should not be exposed to the client.
A run time binding of action names to action implementations (bound to
a portlet app) with security constraints would be ideal.  Something
similar to the way URIs map to actions in struts (but obviously in
this case, we can't use a URI pattern, but rather a request
parameter).

>
> Im also thinking the actions could be methods on portlets.
> I guess Im still in the 'thinking' stage here, thinking out loud on a
> public mailing list...
>
> > For my particular use case, I'm not just triggering server side
> > business logic, I'm also writing XML to the response.  And actually,
> > if you could control the response headers and write to the response,
> > that would also solve the download of arbitrary binary data problem.
> >
>
> Almost sounds to me like you want a portlet that acts upon an xml
> content type. Calling the portlet pipeline, no?
>
> The challenge there is having the Javascript send parameters to the
> portlet. Perhaps the portlet pipeline should take the servlet request
> parameters, if on a portlet pipeline, and send them on to the portlet as
> portlet render parameters.
>
> This sounds interesting

I suppose I should look into this possibility for my immediate
requirements.  To be honest, I haven't really experimented with the
portlet pipeline as there isn't much documentation (at least that I
found) about it.  I only recently was tipped off by cubehead that you
can invoke a portlet using a URL of the form:

/jetspeed/portlet/?portlet=portlet-app::portlet-name&entity=id

By the way, I assume this invokes the portlet's render method, is
there a way to invoke the processAction?

I have found that when I call a portlet page with request parameters
in the URL, they are accessible from within the RenderRequest of all
Portlets in the page. Wouldn't the same apply to the portlet pipeline
(ie. if I appended additional request parameters)?

If so, since render parameters and request parameters are accessed via
the same API call (request.getParameter), it may not be necessary to
actually create render parameters from the request parameters since
that would only make them "sticky" (ie. they'd still be present for
subsequent calls to the render method).

>
> > Of course it would be sweet if there were something in the
> > portal/portlet spec that we could leverage here (and not be so
> > proprietary), but I just don't think there is anything that fits the
> > bill...
> >
> The portlet spec team just started discussing this
> Unfortunately Im a few weeks behind on my emails there :(
>
>

Well no rush, I mean, I think it is better to throw ideas around first
and have a well thought out solution. :)

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...

[David Sean Taylor]

Aaron Evans wrote:

> On 3/23/06, David Sean Taylor <david@...> wrote:
>
>>Aaron Evans wrote:
>>
>>>On 3/23/06, David Sean Taylor <david@...> wrote:
>>>
>>>
>>>>What do you think about a new feature where Jetspeed can execute secured
>>>>ajax actions in portlet applications. The actions would just be POJOs
>>>>like in the Jetspeed AJAX API, and we could secure the actions in the
>>>>security policy
>>>>
>>>
> ets> >
>
>>>Yes, that sounds like a dandy idea.  But it might be nice if the
>>>actions were actually implementations of some simple interface whose
>>>'doAction' method or whatever had access to the request and response.
>>>
>>
>>Take a look at the interfaces here in the Jetspeed API:
>>
>>http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/org/apache/jetspeed/ajax/package-summary.html
>>
>
>
> I had a look.  The AJAXService says it "Performs invocation of the
> actual AJAX request and returns a result object to converted into
> XML.". It is unclear to me how one controls what the resulting XML
> would look like.
>

The uppercase AJAXService is the one I do not use, so Im not the person
to respond on that. (We really need to combine these 2 prototypes into
one solution). Take a look at AjaxService and  see if that helps

>
> Yes, I agree.  Java class names should not be exposed to the client.
> A run time binding of action names to action implementations (bound to
> a portlet app) with security constraints would be ideal.  Something
> similar to the way URIs map to actions in struts (but obviously in
> this case, we can't use a URI pattern, but rather a request
> parameter).
>
There is already something in place for that, see ajax-layout.xml, a
Spring configuration solution

Lets not let this feature (executing ajax actions on portlets or pojos)
not slip through. Could you create a JIRA issue for a new feature with a
brief description of how you would like it to work?

Thanks

>
>
> I suppose I should look into this possibility for my immediate
> requirements.  To be honest, I haven't really experimented with the
> portlet pipeline as there isn't much documentation (at least that I
> found) about it.  I only recently was tipped off by cubehead that you
> can invoke a portlet using a URL of the form:
>
> /jetspeed/portlet/?portlet=portlet-app::portlet-name&entity=id
>

The portlet pipeline has been around for a while.
Its embedded in several other portal products, including Jetspeed 1.6.
I have slides describing it from the 2005 ApacheCon. I will try to get
those into the main documentation stream. Not sure if you are on
jetspeed-dev mailing list or not. See the commits that have gone in this
week with the Jetspeed Desktop feature. We are using the portlet
pipeline quite a bit there, lots of examples.

> By the way, I assume this invokes the portlet's render method, is
> there a way to invoke the processAction?

Timely question.
Steve and I are working on a solution for exactly that today.
Recommend subscribing to jetspeed-dev and monitor the commits

>
> I have found that when I call a portlet page with request parameters
> in the URL, they are accessible from within the RenderRequest of all
> Portlets in the page. Wouldn't the same apply to the portlet pipeline
> (ie. if I appended additional request parameters)?
>
> If so, since render parameters and request parameters are accessed via
> the same API call (request.getParameter), it may not be necessary to
> actually create render parameters from the request parameters since
> that would only make them "sticky" (ie. they'd still be present for
> subsequent calls to the render method).

Yup, this is something Im looking into too. I need to do a bit more
digging and I'll comment back later

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@...
For additional commands, e-mail: jetspeed-user-help@...