Changes between Version 4 and Version 5 of TracDev/Proposals/PortalTrac

Timestamp:

Jun 16, 2011, 10:17:30 PM (13 years ago)

Author:

Carsten Klein <carsten.klein@…>

Comment:

revised initial information on portlets

TracDev/Proposals/PortalTrac

@@ -45 +45 @@
  - trac.web.main will be adjusted so that it will detect a portal instance or use the default env-parent-dir behaviour if no such environment exists;
 
- - Portal specific extension points (IPortal...) will be introduced, which have to be extended upon by !PortalComponent derived components. All portal components must be registered with the trac.portal.component entry point;
+ - Portal specific extension points (IPortal...) will be introduced, which have to be extended upon by user or system provided components. All portal components must be registered with the trac.portal.plugins entry point;
 
- - A new trac.portal.api Portlet API and Portal Component API will be introduced, with IPortlet being the sole portlet extension point in the system. Portlets will also be standard Trac Components, and they must be registered with the trac.portal.portlet entry point;
+ - A new trac.portal.api Portlet API and Portal Component API will be introduced, with IPortlet being the sole portlet extension point in the system. Portlets will also be standard Trac Components, and they must be registered with the trac.portal.portlets entry point;
 
- - Portlets serve as content providers, they themselves are using so called content aggregators, which in turn make use of so called content sources. Portlets can support rendering content in multiple different formats, based on so called content types. The least common denominator is considered text/plain, however, in a web based environment we consider it to be text/html. A portlet that supports rendering of its content in for example text/html and text/rdf+xml or even text/atom+xml, will adopt to content-type specific user requests, provided that the portal allows one to retrieve a feed from a single portlet at a time...
+ - Portlets serve as content providers. Some of them might even serve as IRequestHandlers. Basically a portlet can choose to provide content that is local to the portal or, they are using so called content aggregators aggregating content from across all of the registered projects. These aggregators, in turn, make use of so called content sources. Portlets can support rendering content in multiple different formats, based on so called content types. The least common denominator is considered text/plain, however, in a web based environment we consider it to be text/html. A portlet that supports rendering of its content in for example text/html and text/rdf+xml or even text/atom+xml, will adopt to content-type specific user requests, provided that the portal allows one to retrieve a feed from a single portlet at a time...
 
  - A new <portlet.../> Genshi directive will be introduced for authoring the portal template;