You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by BaTien Duong <ba...@dbgroups.com> on 2003/12/17 20:09:44 UTC

Re: Portlets Framework

Howdy:

Here is a framework we are working on with very promissing results:
    1) User request is submitted to Struts request/response framework 
RequestProcessor (based on Struts-chain)
    2) RequestProcessor  passes information via ServletWebContext and 
looks into its Catalog of requested ServiceAction.
    3) The ServiceAction uses all facilities of current Struts such as 
ServiceForm, Validation, etc.
    4) The portal page has both static and dynamic fragments. The 
dynamic fragments are passed from ServletWebContext to PortletProcessor 
with contents stored in PortletWebContext. Note that ServletWebContext 
and PortletWebContext are just maps of name/value, same as cornerstone 
IContext.
    5) PortletProcessor calls requested portlet(s) passed via contents 
in PortletWebContext.
    6) Individual portlet  calls its processActions and render which are 
2 cornerstone services for component customization, component 
relationship, control flow customization, and component management. We 
are combining Cornerstone services and Hivemind services into our own 
services. This enable us to leverage on open-source low level 
developments and use it as a backdoor connection for different portlet 
applications which can be replaced with a more vendor neutral of JMS 
service. Security is a concern here, but if you wire various portlet 
applications together you are supposed to know what you are doing. The 
Struts pattern of service firewall such as ServiceForm can be used to 
avoid Trojan hourses.
    7) Results of portlet renders recorded in PortletWebContext are 
returned the ServiceAction, which overwrite its contents in 
ServletWebContext with the contents in PortletWebContext. The results in 
ServletWebContext is passed to Struts-chain ResponseProcessor.
    8) The ResponseProcessor passes ServletWebContext to the selected 
presentation engine, which can be any framework: JSP, JSF, Flex, XForm, 
WML, etc. The presentation engine renders the response using contents 
from ServletWebContext.

Hope this may stimulate into the best flexible framework that we can all 
benefit.

I thought this may be relevant to both Jetspeed and Struts, so I cross 
post in both. Sorry if it bothers you.

BaTien
DBGROUPS

Weaver, Scott wrote:

>Hi Punit,
>
>  
>
>>For example 
>>if we want to apply some simple filter on request, which is 
>>the best place (if any) do to this? How to install common 
>>portlet filters?
>>    
>>
>
>
>Remember, a JSR-168 compliant portal supports portlet applications as
>indivdual web apps deployed to the respective servlet container, this a
>requirement of the spec. Hence, you can use servlet filters within
>individual portlet apps to attain the filter functionallity required by each
>indivdual portlet application and the portlets contained within.  It was
>crucial to the spec that it leverage as much functionallity from the servlet
>standard a possible so as to make portlet and servlet develop easy/similar
>as possible.
>
>Hth,
>*================================* 
>| Scott T Weaver                 |
>| <we...@apache.org>            | 
>| Apache Jetspeed Portal Project |
>| Apache Pluto Portlet Container |
>*================================*
>
>  
>
>>-----Original Message-----
>>From: Punit Pandey [mailto:pandeypunit@hotmail.com] 
>>Sent: Wednesday, December 17, 2003 8:03 AM
>>To: lportal-development@lists.sourceforge.net; 
>>exo-developers@lists.sourceforge.net; 
>>jetspeed-dev@jakarta.apache.org; portlets
>>Subject: Portlets Framework
>>
>>
>>Hello,
>>We are in the process of developing one framework for 
>>portlets. The objective is to apply all possible patterns and 
>>also try to simplify the development process.
>>
>>The biggest challenge for developing portlet-framework, seems 
>>to us, is unavailability of controller servlet. In most of 
>>the JSP/Servlet-frameworks (e.g struts) the request always 
>>goes through the controller servlet. But in case of a portal, 
>>we do not have any such control. Can anyone tell me how to do 
>>some sort of request-preprocessing for a portlet? For example 
>>if we want to apply some simple filter on request, which is 
>>the best place (if any) do to this? How to install common 
>>portlet filters?
>>
>>Regards,
>>
>>Punit Pandey
>>
>>=================================================
>>http://portlets.blogspot.com - Portlets blog 
>>http://groups.yahoo.com/group/portle> ts/ - Portlets Discussion Group
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
>.
>
>  
>