portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James H Nguyen <james.ngu...@us.ibm.com>
Subject RE: is it possible to use Struts with Jetspeed
Date Mon, 24 Mar 2003 21:35:07 GMT




from what i've read so far in the portlet api draft in the jetspeed cvs
project. there's a PortletAdaptor class that most portlets will extend to
obtain the portlet API hooks such as the portlet container context etc etc.
since i've been working with struts for the few months on a client
engagement, i've managed to become familiar enough to the point where i
think we can extend struts from the RequestPreprocessor class and truncate
all the unnessary servlet calls and provide for the simplified portlet
interface. most of the struts dispatch actions come from the
RequestPreprocessor class since struts v1.1x.
the problem is i have all these ideas, but am stuck on weather i should
implement them or not because i would hate to be duplicating work that
someone else already has. and if that's the case, i would like to
contribute in other areas where needed. =) i would love to see jetspeed be
the leader in opensource portal server projects with the correct best of
practices approach to portal servers.
how would come about being a commiter for jetspeed and help out? i
currently already have the latest cvs head and it's running great under
websphere studio advanced developer 5. only problem was that it wouldn't
run on WAS5 server... that i will try to figure out later, but for now i'm
testing it with tomcat 4.1.x which runs great.
please let me know. i'm dying to see how jetspeed 2.0 looks. ;)
james nguyen
ibm global services
ams enterprise application development
james.nguyen@us.ibm.com
>>>From what he told me, committer access is required to get a hold of 2.0.
I am a committer, but I haven't had a chance to peruse 2.0.
>>That does not mean we can't start in the 1.4x code base. I think we have
to take it slow, first try delegating Struts' Actions to Struts from within
the current Jetspeed implementation. To do this, I have a feeling are going
to have to get our hands dirty we it comes to inner workings of Struts and
knowing what pieces we need.
>>After we have some comfort level with that, then we can look at a
pluggable framework model for Jetspeed. This would allow the end developer
to choose his/her framework of choice using a thin layer of abstraction
between jetspeed and said framework.


>>*===================================*
>>* Scott T Weaver *
>>* Jakarta Jetspeed Portal Project *
>>* weaver@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