Seam Portlets

[asdf_zxcv]

I just looked at Seam and am very impressed with the architecture and the problem it is solving

I was wondering about the time line for providing PortletContext support and availability of JSR168 support in general

IMHO, portlets provide true plug-n-play UI functionality at the "subsystem" level - and allow units of functionality to be built/rolled out

If any help is needed in speeding this up, I can help

Thanks

--Arun

Arun Rao

[theute]

Arun,
i just came up with a start, so that you can use Seam to write your portlets. The problem so far is that you can only have 1 portlet on that page... (Not good for a portlet). When you act on other portlet it re-renders the Seam portlet and breaks everything.

We need to find a way so that it would work on any portal for any JSF implementation, and that's the tricky part. We are thinking of caching the result of the page so that there is no call to render the portlet anymore. It can easily work on JBoss Portal with MyFaces since JBoss Portal let you cache the pages but wouldn't work with all those other portals that don't provide that (since it is not a requirement from the spec).

Of course, any help or idea is welcome.

[asdf_zxcv]

Hi Thomas

Great work on Seam ! just what the doctor ordered

I wonder if building a seam "container" that holds components and rendered using something like Tiles will help

Is your intial work in CVS ? Would like to take a look and understand - Still getting up to speed on Seam

Thanks

[gavin.king]

Actually, the problem Thomas describes can be partially solved with portlet response caching, and that is a standard (though not a *required*) part of the portal spec.

So it is possible to use Seam in a portal today (if you grab current CVS). Please try it out!

However, correct multi-window operation (ie. isolated conversations in multiple windows) might *never* be possible without special support in the portal engine.

The basic problem is that I have not yet found a safe way to detect that a render is a result of a browser GET request (which should start a new isolated conversation), or a result of an action on another portlet (which should propagate the existing conversation).

(You would think you could do this just by calling HttpRequest.getMethod(), but supposedly some portals do a browser redirect after portlet actions.)

Even if there is an easy way to detect this, it is still a little bit tricky to implement a caching layer that is aware of this stuff. But that is at least in principle solveable.

If we can't figure out a good way to do it in a standard way, we are going to build whatever we need into JBoss Portal, and then try to push it into the next rev of the portal spec.

Whatever, my goal is certainly to have multi-window operation working in JBoss portal sometime in Jan.