portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Orrego" <orr...@inflexa.com>
Subject RE: Struts-based portlet applications
Date Fri, 30 May 2003 17:41:08 GMT
http://sourceforge.net/projects/basicportal/



-----Original Message-----
From: Mete Kural [mailto:metek@touchtonecorp.com]
Sent: Friday, May 30, 2003 3:39 AM
To: Jetspeed Developers List
Cc: jetspeed-user@jakarta.apache.org; Weaver, Scott
Subject: Re: Struts-based portlet applications


Hi guys,
What I understand more and more is that the ways Struts needs to be tweaked in order to develop
a "portal server" is very different
than the way Struts has to be tweaked in order to develop "portlets". I am interested in doing
both, but at this point I am more
interested in how to tweak Struts to develop portlets. Once the JSR-168 is public in a few
weeks God willing, I would like to make a
proposal to the Struts developers to create a new folder under the /contrib folder in the
Struts CVS and get together a bunch of
interested individuals to develop the classes that are necessary to build JSR-168 portlets
with Struts. I think there would be
individuals interested in several different organizations including open-source portal projects
and portal vendors. I know that
Liferay open-source portal developer Brian is interested in this. Maybe IBM will be interested
as well since they have already
provided a solution to build JSR-168 portlets with Struts in WebSphere Portal. I assume you,
David and Scott, are interested. Do you
know others who are interested in such an effort?

Thanks,
Mete

---------- Original Message ----------------------------------
From: David Sean Taylor <david@bluesunrise.com>
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Date:  Thu, 29 May 2003 23:50:24 -0700

>
>On Thursday, May 29, 2003, at 05:56  AM, Mete Kural wrote:
>
>>
>>> 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?).
>yes
>
>> 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?
>>
>Wrapping the Action Portlet with the Portlet interface doesn't sound
>clean.
>I opted for the request processor, but ended disliking that approach
>too (for the entire portal server)
>
>Interesting, that attached from IBM, thanks.
>He didn't really go into the problems he had with two-phase processing
>of the portlet API.
>I don't really have a solution for that one.
>To me the best solution would be to have Struts as the portal server,
>since then we could make the specific call to the Struts action in the
>action phase, and then in the render phase process the JSP.
>But in doing so, I found I was compromising the pureness of a portal
>application, and instead writing a bastardized portal server just to
>work with Struts.
>I think you all should consider writing a Struts implementation of the
>Portlet API, or perhaps working with the Basic Portal guys on that.
>Or working with Jetspeed, and try to support Struts as portlet
>applications
>Also, I don't see a good solution for writing your Struts application
>once, and running it as a servlet or a portlet.
>In my mind they are different.
>if you want to use your servlet only in a portlet with no portlet
>interaction then use an IFrame or WebPage portlet.
>
>We also considered writing our aggregation with tiles, but again I
>didn't find tiles suitable for the task.
>I believe one Jetspeed developer fancies writing an aggregation engine
>with tiles. Thats fine by me, as long as we don't corrupt the portal
>design.
>
>> 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.
>>
>
>--
>David Sean Taylor
>Bluesunrise Software
>david@bluesunrise.com
>+01 707 773-4646
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
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