Hi,
I'm one of those portlet users. I could only make some suggestions and
outline what has worked so far me. Then, committers could decide what
and how to incorporate in the code. Subsequently, I could test releases
of MyFaces that don't need workarounds. Here are a few things:
1) I reported a problem yesterday on initialization of the
SerialFactory. This is actually more general than portlets. It turns out
state serialization is initialized in a listener declared in the MyFaces
TLD. I'm not 100% sure about this, but it seems that this works because
of a side effect of the way servlet containers work: usually they are
also JSP containers and scan JARs for tag libraries etc. However, an
application that does not use JSPs or that (as was my case) deploys
myfaces as a shared, server-wide library, breaks those assumptions and
the startup listener declared in the TLD is not called. MyFaces
initialization should probably be exposed as a well-documented API and
it should all be in one place.
2) The main problem with portlets is the use of extended components
(file upload, and components that require client-side libraries). File
upload works with a servlet filter in standalone applications. But
servlet filters don't work on portals. In a portal environment,
multipart processing can be placed in a "generic portlet" base class.
This is not done in MyFacesGenericPortlet, so I created my own by
copying over source code. As for JavaScript stuff, this will depend on
portlet containers. I think all of them have some means to plug in
common client-side resources. In WebSphere for example, one writes
themes and skins as JSP pages so it's easy to manage client-side code
sort of manually. My suggestion would be to expose this in MyFaces as a
well-documented API. The portlet spec will evolve at some point to
handle this requirement in a standard way. Currently, I'm not using any
of the components that require a JS library because I don't know how
much time I would loose to make it work. Source code in MyFaces is not
easy to navigate, it's not downloable, you have this "shared" thing with
package names that change during build time etc., so I'm reluctant to
dig into it to much.
For file upload, the solution is pretty simple. Here is how it works for
me:
a) I'm using commons-fileupload
B) in the processAction portlet method of MyFacesGenericPortlet, I have:
public void processAction(ActionRequest request, ActionResponse
response)
throws PortletException, IOException
{
if (log.isTraceEnabled()) log.trace("called processAction");
if (sessionTimedOut(request)) return;
setPortletRequestFlag(request);
if (PortletFileUpload.isMultipartContent(request))
request = new MultipartActionRequestWrapper(request);
FacesContext facesContext = facesContext(request, response);
// etc...
MultipartActionRequestWrapper is a simple wrapper class I wrote for an
ActionRequest that does the multipart processing based on
commons-fileupload facilities. The rest of the code is the same, relying
on the ActionRequest interface.
I remember or encounter other glitches, I'll post them.
Best,
Bolerio
-----Original Message-----
From: Mike Kienenberger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 12:22 PM
To: MyFaces User mailing list
Subject: Portlet examples needed by portlet/MyFaces users
We've had a number of bugs posted by users of MyFaces who are also
using Portlets.
Would one of those users like to contribute some MyFaces portlet
examples to aid us in fixing and debugging your issues? I don't
think any of the currently-active MyFaces committers are using
portlets, so it's hard for us to see your problems or test patches.
Thanks!
