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 as a JSR-168 Portlet Framework
Date Thu, 18 Sep 2003 08:11:10 GMT
Hi Tim,

Good to hear that you are pushing Struts as the portlet framework at your company. You may
want to also get engaged in the struts-dev mailing list and send your feedback to them. Craig
wrote that it would be nice if someone wrote the portlet version of the request processor
extension for the new decomposed request processor that is being designed for Struts 2.0.
The code can be found in /contrib/struts-chain in Struts CVS. So far there is only the servlet
extension. If any of you could work on a portlet extension, that would be great. You can contact
struts-dev about this.

Thanks,
Mete

---------- Original Message ----------------------------------
From: "Tim Reilly" <tim.reilly@consultant.com>
Reply-To: <jetspeed-user@jakarta.apache.org>
Date:  Wed, 17 Sep 2003 20:50:18 -0400

>Excellent!
>I just spent the afternoon "lobbying" for Struts use at the portlet level...
>I'm not sure I did very well.
>
>In the end it came down to:
>
>* Each advocate of methodologies will present our representative
>use-case:"Add Client Site" developed in their respective methodology this
>coming Monday (So for me that means using IBM portlet revision of
>Struts1.1-b2 to develop this functionality for Mon.)
>
>The main alternate contenter is using the MVC portlet. This implies coding
>the if..else if..else if..else in the controller; however the point was made
>that since the responsibilities of a portlet should not be as large as that
>of a "normal"  struts application this is acceptible.
>
>* Someone estimated a factor of 4 as the time required to develop in Struts
>versus not developing with Struts. This is also the person in our group with
>the most Struts experience, so I can't really argue against... except
>perhaps to capture my time and present that as well on Monday.
>
>* Others in the group expressed apprehension to the fact that we are using a
>modified version of Struts. I mentioned based on a previous post on this
>list, that the Struts community is behind supporting portlets as well as
>servlets. Your posting here reaffirms this for us so .. thank you.
>
>* I mentioned that although Struts adds complexity it provides; a) a
>well-known framework for application development. b) Would ease certain
>development and maintainence. c) Provide a proven framework for validation.
>d) Allow new team members to "get up to speed" faster since the framework is
>so well known.
>
>* I added to the discussion ... that development time may not be a factor of
>4 - if solid tools are used to generate certain elements; for example - the
>struts-config.xml? Stubs for our Actions and Forms. Does anyone have any
>favorite tools that may help here? I've seen EasyStruts on
>eclipse-plugins.2y.net but have not used.
>
>I'd love to hear people's thoughts on this topic.
>
>[I realize this is perhaps off-topic for jetspeed-dev, so I am posting it on
>jetspeed-user@jakarta.apache.org with same for reply-to; e.g: Trying to move
>sub-thread from dev to user?
>If it doesn't work right please just reply to
>jetspeed-user@jakarta.apache.org]
>
>Thanks. Hope hear your thoughts.
>
>
>> -----Original Message-----
>> From: David Sean Taylor [mailto:david@bluesunrise.com]
>> Sent: Wednesday, September 17, 2003 2:29 AM
>> To: Jetspeed Developers List
>> Subject: Re: Struts as a JSR-168 Portlet Framework
>>
>>
>>
>> On Tuesday, September 16, 2003, at 09:25  AM, Mete Kural wrote:
>>
>> > You are right, David, Struts 2.0 does not claim to be working at the
>> > portal layer. That is, as you say, the portal server's concern such as
>> > Jetspeed. Struts 2.0 aims to be a framework for building portlet
>> > applications (JSR-168 compliant).
>> >
>> > Right now, Struts committers are re-designing the RequestProcessor to
>> > make it flexible for portlet environments as well as plain servlet
>> > environments. They need feedback from the portal community in order to
>> > make sure that the re-design is done in a way that effectively
>> > satisfies the needs of portlet environments. Please take a look at the
>> > code in the Struts CVS at contrib/struts-chain. I would recommend you
>> > to ask any questions to the Struts committers in the struts-dev
>> > mailing list.
>> >
>> Sounds great!
>> I will have a look at the code in contrib/struts-chain
>>
>> --
>> David Sean Taylor
>> Bluesunrise Software
>> david@bluesunrise.com
>> +01 707 773-4646
>> +01 707 529 9194
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>---------- Original Message ----------------------------------
>From: David Sean Taylor <david@bluesunrise.com>
>Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
>Date:  Tue, 16 Sep 2003 16:45:50 -0700
>
>>
>>On Tuesday, September 16, 2003, at 05:23  AM, Mete Kural wrote:
>>
>>> Hello all,
>>>
>>> The topic of adapting Struts to be a portlet framework compliant with
>>> JSR-168 was discussed earlier. I remember that some of you were
>>> interested in contributing to such a project. Now is the opportunity.
>>> One of the goals of the next generation of Struts, Struts 2.0, is
>>> "Transparent support for a portlet environment (JSR 168)". Development
>>> for Struts 2.0 has already begun little by little. Here is the roadmap
>>> page for Struts:
>>> http://jakarta.apache.org/struts/status.html
>>> Please scroll down for the part that is titled "Struts 2.0.x" and then
>>> the part under it that is titled "Portlet (JSR-168) Whiteboard".
>>> Struts committers are seeking out the help of others to make
>>> suggestions and improvements to these initial development stages of
>>> Struts 2.0. Jetspeed developers and users can be especially useful in
>>> making sure that Struts 2.0 addresses the needs of portlet developers.
>>> You can do this by sending your feedback to the Struts committers.
>>> Here is what Craig McClanahan wrote about building portlet support in
>>> Struts:
>>>
>>> "One approach to dealing with it has (in fact) already begun -- in the
>>> "contrib/struts-chain" subdirectory in the CVS sources is the
>>> beginnings
>>> of a refactoring of the standard RequestProcessor based on the
>>> "commons-chain" package in the Commons Sandbox.  If this actually
>>> works,
>>> two really good things might be able to happen:
>>>
>>> * It'll work for both servlets and portlets (you can see how the
>>> command implementations are being abstracted so that the chain will
>>> just do the right thing for each environment).
>>>
>>> * It is likely to be backwards compatible with Struts 1.1 as well,
>>> possibly with some restrictions yet to be discovered.
>>>
>>> The best way to get involved would be to check out CVS sources for
>>> both jakarta-struts and jakarta-commons-sandbox, become familiar with
>>> the code
>>> referenced above, and start making suggestions and improvements.  A
>>> really good starting point would be portlet-specific implementations
>>> of all the
>>> commands that currently have only servlet-specific implementations. "
>>>
>>> I would recommend anyone who is interested to give feedback to the
>>> Struts committers on the struts-dev mailing list.
>>>
>>> Thanks,
>>> Mete
>>>
>>
>>Thanks for the invitation.
>>
>>Are there any plans for integrating with Struts with Jetspeed-2?
>>I see Jetspeed as doing one thing well: a portal server.
>>Struts is good for web (and soon to be portal) development.
>>Separation of concerns.
>>I would see Struts working at the portal application layer, not at the
>>portal layer, which is the concern of Jetspeed.
>>Anyway thats just my view...
>>
>>
>>--
>>David Sean Taylor
>>Bluesunrise Software
>>david@bluesunrise.com
>>+01 707 773-4646
>>+01 707 529 9194
>>
>>
>>---------------------------------------------------------------------
>>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-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-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