JBoss Portlet Container integration into 2.7

[julien1]

I worked on the integration of the portlet controller, here is the status:

- InvokePortletWindowActionCommand and InvokePortletWindowRenderCommand are implemented

- the different controller context are implemented but do not implement coordination except that there is a basic support for public render parameter support using the page scope.

- added an InvokePortletWindowResourceCommand that will serve resources.

- I forked the PortletRequestEncoder and PortletRequestDecoder classes and their test case in order to extend them for resource serving and public render param. They will be removed from the portlet module later as they are not used anymore.

- I started some integration of the JBPC samples in the core-samples module. For some reason of the 2 google portlet does not work (??).

[julien1]

what needs to be done in the short term:

1/ extend encoder/decoder to implement resource serving urls

2/ extend encoder/decoder to implement public navigational state changes

3/ extends PortalObjectCommandFactory and PortalObjectURLFactory to take in account the InvokePortletWindowResourceCommand

4/ implement handling of resource invocation response in InvokeWindowCommand and return a StreamResponse to the controller.

with that we should have support for resource serving and basic support for page render parameters.

[julien1]

I am looking at the encoder/decoder thing, it's not trivial.

[julien1]

this is now experimentally implemented

what needs to be done in the short term:

1/ extend encoder/decoder to implement resource serving urls

2/ extend encoder/decoder to implement public navigational state changes

3/ extends PortalObjectCommandFactory and PortalObjectURLFactory to take in account the InvokePortletWindowResourceCommand

4/ implement handling of resource invocation response in InvokeWindowCommand and return a StreamResponse to the controller.

with that we should have support for resource serving and basic support for page render parameters.

[julien1]

I have added support for public render parameters with implicit sharing. The matching strategy uses the "same qname" strategy.

There is an example that I added in basic samples that show portlet sharing parameters with various option to manipulate them.

I have also added back support for the app-id feature that was making some of our samples not work correctly. I added an app-id element in jboss-portlet.xml and am in favor of deprecating jboss-app.xml (but keep support for it in 2.7 with a warn on the console).

[julien1]

I just did the implicit event distribution that use also the same event qname distribution strategy.

[julien1]

I have adapted the content provider framework for rendering to use public render parameters as it was planned.

In order to be content driven a portlet needs to declare and manage the public render parameter "uri" with the namespace "urn:jboss:portal:content".

At runtime the portal will set the declared parameter with the window contained URI.

What is remaining to be done in that area is :

1/ update of the faces portlet component to handle a portlet generated event as a JSF event

2/ implement a special event that signals the end of the configuration activity during content edition using the same "urn:jboss:portal:content" namespace with an appropriate name. When this event is received it should tells the JSF admin portlet that content is configured. Today that already exists but relies on a special action parameter which is the previous way to communicate.

I experienced the impossibility to use the portlet content editor in the admin due to stack traces, so that should be solved asap.

[theute]

I experienced the impossibility to use the portlet content editor in the admin due to stack traces, so that should be solved asap.

It is partially solved. I solved an issue, but a new one popped out. At least now you should be able to use most of the admin portlet (except the content editor), i'm still working on it (like on a big steak)

[theute]

The bugs are now fixed in SVN.

Still, as you said:

What is remaining to be done in that area is :

1/ update of the faces portlet component to handle a portlet generated event as a JSF event

2/ implement a special event that signals the end of the configuration activity during content edition using the same "urn:jboss:portal:content" namespace with an appropriate name. When this event is received it should tells the JSF admin portlet that content is configured. Today that already exists but relies on a special action parameter which is the previous way to communicate.