Hi BaTien, Any chance of contributing this? If it is portlet-specific, it would make a fine addition to portals.apache.org if/when we get it rolling.
Regards, *================================* | Scott T Weaver | | <[EMAIL PROTECTED]> | | Apache Jetspeed Portal Project | | Apache Pluto Portlet Container | *================================* > -----Original Message----- > From: BaTien Duong [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 17, 2003 2:10 PM > To: Jetspeed Developers List; Struts Developer List > Subject: 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 | > >| <[EMAIL PROTECTED]> | > >| Apache Jetspeed Portal Project | > >| Apache Pluto Portlet Container | > >*================================* > > > > > > > >>-----Original Message----- > >>From: Punit Pandey [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, December 17, 2003 8:03 AM > >>To: [EMAIL PROTECTED]; > >>[EMAIL PROTECTED]; > >>[EMAIL PROTECTED]; 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: [EMAIL PROTECTED] > >>For additional commands, e-mail: > [EMAIL PROTECTED] > >> > >> > >> > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > >. > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
