Using Adobe Flex in JSR-286 Portlets 

Another approach to avoid full page refreshs, using Flex and leveraging the portlet framework in Portal 6.1, could be to let Flex communicate via SOAP with the WSRP producer for the given portlet. This would be a relatively clean solution since WSRP is also an open standard supported by many portal vendors. The Flex client would then act as a WSRP consumer. See also { Link } for WSRP support in Websphere Portal.

Brandon,

Sorry for the late answer, I wish I had more time to investigate this. I can understand very well, that you would like to fully exploit the portlet api and other features of Portal, using Flex and only partial page updates. And I am convinced that this is possible - you only need to take some things into account.

Here are some preliminary results: CSA works reliably with regular portlets that produce HTML markup only - I have tested it. So CSA has only a problem with the way I have written the Flex sample portlets.

My current theory is that, since CSA somehow rewrites or redirects the portlet urls for the AJAX background requests, it only can do this url rewriting for portlet urls found in <a href> and <form action> tags - that's my assumption. So it doesn't find the portlet urls that I am passing to the Flex application via the html <object> tag.

If this theory holds true, I see one immediate solution for your problem:

Change the way the portlet urls are invoked by the Flex application: One could e.g. write out the portlet urls needed for the flex app into regular html in a hidden <div> and invoke (click) them from Flex via the JavaScript bridge - see also { Link }

As mentioned in my previous postings, using the REST service API (ATOM Feeds) and the client portlet programming model as documented in the info center could be two alternatives, but this one would be the simplest solution, I believe.

regards, Konrad

Hi Brandon,

First of all, sorry for the late reply, this wiki does not seem to provide the capability to notify people, yet.

I had tested the Flex portlet samples to also work with the PortalWeb2 theme which leverages CSA.

The PortalWeb2 theme is a bit unconventional - not sure whether this applies to CSA in general - but when you switch the portlet mode to edit, you get the view mode displayed again and _below_ you get the edit mode dialogue. The idea of CSA is to only refresh the portlet windows that need it. Unfortunately, Gene and I both had to realize that as it stands for Portal 6.1, all portlet windows on a page get refreshed using the PortalWeb2 theme. So all you currently win is that the navigation does not get reloaded with each server-side triggered action.

I have reported this phenomenon to a colleague of mine who has been involved in the development of CSA, I assume they'll be correcting this behavior in the future.

Hi Konrad,

We deployed the sample portlets and were able to run them in the traditional portal mode. We then enabled CSA in an attempt feel the difference between Traditional vs. CSA. The portlets would paint, however the portlets didn't function properly. When clicking on the edit button, the page refreshes and remains in read mode. Took a look at the link you provided and I believe we aren't doing anything out of line. We applied 'no skin' as suggested in the WEB2 theme doc. Is there any additional configuration required for CSA to function properly outside of the Theme being set to PortalWeb2?

Thanks,

Brandon

> Hi Konrad,

>

> I finally was able to install Portal 6.1. I installed the war file

> that you provided, created a page containing the two Flex portlets,

> and created the wiring per your instructions. Everything works

> fine, except that any actions taken within the "Flex Portlet" or

> "Flex Cms History Portlet" results in whole page refreshes. For

> example, when clicking on a version within the "Flex Cms History

> Portlet", the page refreshes.

> [...]

> Could you shed any light on this? I think you mentioned in a

> previous email to me that this example should show how partial page

> refreshes are possible. Was there an extra step or two that I

> missed that would enable partial page instead of whole page refreshes?

>

> Any help you could provide would be greatly appreciated!

> Thank you, -Gene

Hi Gene,

The demo does partial page refreshes when it loads the data into both the CMS Editor and the CMS History list. For switching portlet modes, coordination between portlets and to process portlet actions you need full page submits if you do it the traditional way.

BUT: what might be interesting to you is switching on the client side aggregation (CSA). This way only the interacting portlet window areas will be reloaded. This has been tested to work with the Flex demo portlets. Here's how to enable CSA for your page:

1. click on the context menu of the tab for your page. Choose "Edit Page Properties"

2. the Page Properties Dialog appears. In the "Theme:" dropdown field, choose "PortalWeb2" and afterwards "OK"

3. Now you will have CSA enabled. Feel the difference by observing what happens when you interact with the portlets now.

See also { Link }

If CSA is also not enough for you, you might like to try the client side portlet programming model for a smoother user experience with Flex. With the latter, though, I have no experience so far. You will need to use the Ajax Bridge available in Flex to profit from that JavaScript based API. Here's the documentation for the client side portlet programming model:

{ Link }

regards, Konrad

> Hello Konrad,

>

> I was recently at the Nashville, USA WebSphere Portal Conference.

> One of my main goals in attending the conference was to find out as

> much as I could regarding Portal 6.1/Flex integration.

> Unfortunately, there was very little, if any, light shed on the

> subject. Instead, what I got was multiple presenters pointing me to

> your wiki article. I must have read the article five times by now.

>

> We currently deploy Flex portlets in a Portal 6.0 environment.

> Therefore, we have to live with the whole page refresh issue.

> However, it was my understanding that Portal 6.1 would allow you to

> perform partial page refreshes, even when using Flex portlets.

Yes, this is correct. In Portal 6.1, with the JSR-286 support, you can do resource serving within the portal context. In Portal 6.0, something similar was also possible using regular servlets (see the Bishop article referenced in the article), but this meant leaving the portal context - so e.g. no portal-based security enforcement etc. So this resource serving is definitely an improvement for client-side triggered partial page refreshs.

> However, I read with great interest, the following comment in your wiki entry:

>

> "Since you cannot throw events from within a serveResource method

> (see [JSR-286], pp. 105), you will have to do full page submits

> using action URLs in order to send and receive events. This will

> interrupt the smooth user experience of Flash."

This comment applied to the eventing feature only, so coordination between different Portlets. As long as you use the serveResource method only for updating the contents displayed on a page (or in our case Flex), everything works neatly. The problem comes in, when you want to manipulate the state of the whole portlet or even other portlets on the same page, since the portal server cannot render a complete new page at this point in time. So resource serving can and should only be used for information retrieval, not for manipulation operations like throwing cross-portlet events, triggering actions, setting public render parameters. This restriction is for avoiding inconsistent user experiences (as explained in the JSR-286 spec).

On the other hand, if you know, that the manipulation only changes state for what is reflected in that part of the page that you are updating with serveResource, this should be absolutely fine (e.g. updating a DB entry and giving back the result with the same request).

>

> So, my questions to you are:

>

> Is this a blanket statement, regardless of the approach you use?

No, it is not a blanket statement, see above.

> Are you saying that partial-page refresh is not possible with Flex-

> based portlets?

No, Flex based portlets are at least just as good for partial-page refreshs as e.g. AJAX widgets.

> Does you example address this issue? (sorry, I have not yet been

> able to use your published war files, since our 6.1 environment is

> still in the process of being built out)

Yes, in my example portlets you can see how a resource URL is handed over to the Flex/Flash object, which in turn invokes this URL in the background to retrieve some more (XML) data, loaded into Flex.

>

> Any light you could shed on this subject would be greatly appreciated!

>

> Thank you,

>

> -Gene