JBossDeveloper

"thomas.heute@jboss.com" wrote:
What you mention first looks like a weird bug in your application, not a flaw.

"thomas.heute@jboss.com" wrote:
"lack of control the developer has over the markup" is actually the best thing, as a developer i don't want to mess with markup, i want my designer to do this job. This is just a matter of components anyway and the components let the designer focus once on the way something has to be rendered.

"thomas.heute@jboss.com" wrote:
I wouldn't prevent users from gaining benefits of JSF for those reasons. JSF is by design more adapted to a portlet environment since it doesn't rely on the HTTP*Servlet*Request.

We are also looking at what is the best framework for creating portlets. We find some issues using Struts. If we use request.setAttribute(...) in an Action class, the variable is not visible in the JSP. The work around is to use request.getSession.setAttribute(...). This is not very elegant, and we have to remove the sessiono attribute later. In addition, the validation from a form is not working. Even though it does not accept the invalid values (which is good), it does not show the error from the JSP <html:errors /> tag. It seems like these 2 problems are related to the fact that variable set by request.setAttribute() is not visible by the forwarded JSP.

We are using JBP 2.2.x + Struts-Bridge 1.0. Does anyone have the same problem? Any help is appreciated.

"Agathon" wrote:
However, when I put on my designer hat, I want to be able to easily modify all the HTML that is produced. Balancing the requirements of developers verus those of designers is tricky business. Unfortunately, in my opinion, JSF leans too far towards the needs of developers while gimping designers.

"danny_hon" wrote:
We are also looking at what is the best framework for creating portlets. We find some issues using Struts. If we use request.setAttribute(...) in an Action class, the variable is not visible in the JSP. The work around is to use request.getSession.setAttribute(...). This is not very elegant, and we have to remove the sessiono attribute later. In addition, the validation from a form is not working. Even though it does not accept the invalid values (which is good), it does not show the error from the JSP <html:errors /> tag. It seems like these 2 problems are related to the fact that variable set by request.setAttribute() is not visible by the forwarded JSP.

We are using JBP 2.2.x + Struts-Bridge 1.0. Does anyone have the same problem? Any help is appreciated.

public class CustomPortletRequestProcessor extends PortletRequestProcessor {
 public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
 HttpSession session = request.getSession();
 ActionMessages errors = (ActionMessages)session.getAttribute(Globals.ERROR_KEY);
 session.removeAttribute(Globals.ERROR_KEY);

 request.setAttribute(Globals.ERROR_KEY, errors);

 super.process(request, response);

 errors = (ActionMessages)request.getAttribute(Globals.ERROR_KEY);

 if (errors != null && errors.isAccessed()) {
 request.removeAttribute(Globals.ERROR_KEY);
 } else {
 session.setAttribute(Globals.ERROR_KEY, errors);
 }
 }
}

I found out what's wrong with the setAttribute. It was because I missed the struts-portlet-config.xml file. Once I specified the attribute names in that file, the request.setAttribute(...) works.

However, the error handling is still not working. In the ActionForm's validate() method, I have something like this:

errors = new ActionErrors();
errors.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage("error.invalidValue"));
....
return errors

The struts-bridge documentation says this is automatically handled by the framework, but the JSP <html:errors /> does not show anything. I will try your CustomRequestProcessor to see what happen.

The CustomPortletRequestProcessor does work. Thanks a million!

Your reply inspired me to look at the struts-portlet-config.xml file again; initially I thought it was useless, since it didn't seem to do anything. The following configuration will allow messages and errors to be injected into the render request context, without having to make use of the CustomPortletRequestProcessor:

<?xml version="1.0" encoding="UTF-8"?>
<config>
 <render-context>
 <attribute name="org.apache.struts.action.ERROR" />
 <attribute name="org.apache.struts.action.ACTION_MESSAGE" />
 <attribute name="org.apache.struts.action.MESSAGE" />
 </render-context>
</config>

This seems to be a general problem with any request attribute you set. The attribute is not visible to the JSP view page.

Adding any attribute name you use to the struts-portlet-config.xml does seem to make it work, but this isn't a very good solution if you're trying to port an existing Struts application which may be using request attributes everywhere. Does anyone have a solution to this problem? The sample struts application on the JBoss web site seems to carefully avoid ever using request attributes, but it seems like standard thing to do.

Thanks.

Agathon explained very well the problem.

On an action phase you get 2 requests, the request attributes don't survive the first request. We actually have the same problem on the JSF-bridge, Stan fixed the problem on the JSF bridge of MyFaces.

Maybe you could push this problem to the Struts bridge developers ?

The last option if it can't be fixed in the Struts bridge would be to customize the portal to do everything in one request but it would bring another kind of troubles