Changes between Version 7 and Version 8 of TracDev/Proposals/PortalTrac

Timestamp:

Jun 17, 2011, 11:16:39 PM (13 years ago)

Author:

Carsten Klein <carsten.klein@…>

Comment:

—

TracDev/Proposals/PortalTrac

@@ -51 +51 @@
  - 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.portlets 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 also be registered with the trac.portal.plugins entry point;
 
- - 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...
+ - Portlets serve as content providers. Some of them might even serve as IRequestHandlerS or IRequestFilterS. 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;
@@ -60 +60 @@
 
  - TBD
+
+
+== GUI Mockups ==
+
+TBD
 
 
@@ -152 +157 @@
 == Discussion of Design Decisions Made ==
 
- - The new entry points trac.portal.component and trac.portal.portlet will keep the standard environments from loading portal level components and they will also help keep the portal from loading standard environment components during initialization of the environment;
-
- - By having two distinguished entry points, the portal is able to separate concerns between portlets, i.e. components that will be evaluated at the template level, and actual portal extensions, for example modules that would provide for portal level preferences and so on.
+ - The new entry point trac.portal.plugins will keep the standard environments from loading portal level components and they will also help keep the portal from loading standard environment components during initialization of the environment;