portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mete Kural" <me...@touchtonecorp.com>
Subject Re: Struts-based portlet applications
Date Thu, 29 May 2003 12:56:00 GMT

>However I think we could support Struts portlets as a special type of 
>portlet application, as a portlet container
>Are you familiar with what a portlet application is?

I kind of am. Basically as I understand, it's a group of portlets that work together to provide
application-level functionality, such as say content management or CRM or an email client
(Am I right?). So what are your ideas on what extensions to Struts are necessary in order
to build portlet applications with Struts as the framework? I would think that an ActionPortlet
class that wraps each portlet with the JSR-168 Portlet interface may be necessary. Maybe PortletRequestProcessor
for event handling functionality at the RequestProcessor layer? 

There was an email in the Struts-user list a while ago about this subject. It may be useful.
I'm copying it here:

From: "Jim Bonanno" <jim5@nc.rr.com> 
To: "Struts Users Mailing List"
<struts-user@jakarta.apache.org> 
Subject: Re: Struts and Portlets 
Date: Wed, 26 Feb 2003 16:46:36 -0500 


I am glad to see the interest in supporting Struts 
applications in a Portal
Server. I worked on adding support for Struts in 
WebSphere Portal, which
added the ability to create Struts applications that 
can be deployed in
WebSphere Portal. We encountered some relatively minor

changes that could be
made to the framework to help support Struts in a 
Portal Server, but there
were other issues as well.  It was not clear how 
receptive the Struts
community would be to some of these suggestions at the

time but it sounds
like the co-existence of Struts and JSR 168 may be an 
important one for the
future. Some of the issues have already been raised 
like ForwardAction and
the chaining of request processors. We had to package 
an implementation of a
request processor, so that meant we also had to ship a

Tiles request
processor that inherited from ours.

There were some general problems that we encountered 
in a Portal
environment. The first was Struts depends on the 
servlet container to
distinguish Struts actions from other requests, as it 
should. In a Portal
server, the URLs use the servlet context of the 
configured Portal. The URL
will have some additional information that the Portal 
server can use to
determine which portlet the user is interacting with, 
and then some
attributes for the portlet. We had to modify the tags 
that created URLs,
like Form and Link, to create URLs to the Portal 
Server and then we added
the Struts action, href, forward, etc as a request 
parameter. The portlet
would then look at the parameter and determine whether

to call the request
processor because it was an action or include a jsp, 
for example. It would
be a real convenience to create a hook in the tags to 
allow creating these
custom URLs. We were able to subclass the link tags 
implementations and
modify the tlds to use our version. That is fine, but 
I think Struts
developers will want to create Struts applications 
that can be deployed in
both a servlet and a portlet environment.

Other changes that we needed dealt with the fact that 
in a Portal Server it
is very easy to add a portlet to a page more than 
once. This could also be
an issue when using Tiles as well. The problem that we

encountered is the
Struts form tag uses the name of the form bean as the 
form name. This name
will not be unique if the same Struts application is 
added to the Portal
page more than once. We had to namescope the name so 
it was unique, but that
forced us to change the dynamic validation tags to 
also create unique names
for the validation function.

We also ran into issues with the response object. In 
Portal, the response
object is committed by the time a portlet gets it, so 
we had to include
instead of forward. The forward was convenient for 
many applications because
you could forward to an action or a dynamic/static 
page. We recursively call
the appropriate request processor for actions as 
needed and use an include
if the URI was for a page. This also meant that 
pageContext.forward in a JSP
would not function correctly, but that turned out not 
to be a big issue
because of the logic forward tag which we could 
modify. This detail may be
specific to my Portal Server.

Portal also has two phase processing, as opposed to 
the servlet's one phase
service method. There are some interesting design 
decisions that need to be
made with how to map Struts processing with Portal's 
two phase processing.
This is a feature in the JSR 168.

The module support in Struts was very helpful to 
support the different modes
in Portal. The portal mode could be used when 
selecting modules so the
developer can create a Struts module for each of the 
portlet's mode, like
view and edit. It was a nice application for Struts 
modules. Portlet modes
are also part of the JSR.

That's just an brief overview of some of the things we

encountered, I don't
want to bore this mailing list with all the details.


---------- Original Message ----------------------------------
From: David Sean Taylor <david@bluesunrise.com>
Reply-To: "Jetspeed Users List" <jetspeed-user@jakarta.apache.org>
Date:  Thu, 29 May 2003 11:15:37 -0700

>
>On Thursday, May 29, 2003, at 03:13  AM, Mete Kural wrote:
>
>> Hello again,
>>
>> With JSR-168 nearing the public draft stage, I was wondering if there 
>> is interest among the JetSpeed community to cooperate together with 
>> the Struts community in order to design and implement a library of 
>> standard classes that make it possible to build JSR-168 portlets based 
>> on Struts. Some ideas that I have are:
>>
>> - Designing and implementing an ActionPortlet class that implements 
>> the JSR-168 Portlet interface and extends ActionServlet
>> - Designing and implementing a PortletRequestProcessor that provides 
>> an event handling model and adapts Struts applications to portlet 
>> applications
>>
>> I'm not an expert in the portlet field but I am just another fellow 
>> who would really love to see a standard library of classes for 
>> converting Struts applications into JSR-168 portlets that everybody 
>> can use instead of rolling their own. I hope JetSpeed experts and 
>> Struts experts will get interested in such a project. What do you guys 
>> think?
>>
>> Thanks,
>> Mete
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
>>
>Im interested.
>I actually tried this a few months ago, wrote my own 
>PortletRequestProcessor and concluded that its the wrong place to 
>integrate Struts.
>Struts is not meant to be a portal server, and it was leading to a 
>conformist style design.
>
>However I think we could support Struts portlets as a special type of 
>portlet application, as a portlet container
>Are you familiar with what a portlet application is?
>I think it would be best to move this discussion to jetspeed-dev, so 
>that other developers could be involved
>
>--
>David Sean Taylor
>Bluesunrise Software
>david@bluesunrise.com
>+01 707 773-4646
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message