Changes between Version 11 and Version 12 of TracDev/Proposals/PortalTrac
- Timestamp:
- Aug 5, 2018, 9:59:42 AM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/PortalTrac
v11 v12 1 [[PageOutline(2-5,Contents,pullout)]] 1 2 2 NOTICE: While the initial idea was based on massively patching the existing trac sources, the portal will instead be a plugin module. However, this requires the availability of the extension point specified in #10226. 3 = Portal Trac 3 4 4 NOTICE: This is a work in progress. Please file your suggestions and comments under ticket #10217. 5 {{{#!box info 6 '''Note''': While the initial idea was based on massively patching the existing Trac sources, the portal will instead be a plugin module. However, this requires the availability of the extension point specified in #10226. 7 }}} 5 8 6 NOTICE: Development on this has already begun and will be made available on !https://github.com/axnsoftware/trac-portal-plugin as soon as I have internet access over at my company's place, duh, damn providers...9 This page describes an approach to consolidating multiple Trac environments under a unified interface, see TracMultipleProjects/MultipleEnvironments. 7 10 8 == The Context == 11 This was started under ticket #10217. 9 12 10 Having multiple Trac instances or projects leaves you basically with two options. 13 == The Context 11 14 12 1. You set up multiple instances of either the Trac standalone server, binding it to either different IP addresses or ports, or configure apache so that you will have multiple virtual hosts prepared for servicing the multiple independent projects, most provably also using different ports for each project. Of course you will also have to configure your resolver, be it either a DNS or your local /etc/hosts db; 15 Having multiple Trac instances or projects leaves you basically with two options: 13 16 14 2. You use the Trac standalone server or a suitable apache virtual host configuration, and Trac's env-parent-dir option to provide a rudimentary index of your projects from which you then can dive into your existing projects; 17 1. You set up multiple instances of either the Trac standalone server, binding it to either different IP addresses or ports, or configure apache so that you will have multiple virtual hosts prepared for servicing the multiple independent projects, most provably also using different ports for each project. Of course you will also have to configure your resolver, be it either a DNS or your local /etc/hosts database; 18 1. You use the Trac standalone server or a suitable apache virtual host configuration, and Trac's env-parent-dir option to provide a rudimentary index of your projects from which you then can dive into your existing projects; 15 19 16 17 == The Problems == 20 == The Problems 18 21 19 22 - While option 1 is definitely more flexible, it leaves you with a lot of host names a/o ports to remember on how to access your projects in the first place; … … 25 28 - And by no means, one will ever be able to search across all projects, nor will one be able to aggregate information from all projects into a single page, for example a dash board, unless you implemented such a feature by yourself, using even more external tools and customizations to get the job done; 26 29 27 28 == The Goals == 30 == The Goals 29 31 30 32 - The portal should be omnipresent in that existing projects and their modules blend into the portal's layout and design, but still allow individual projects or nested portals to provide a custom logo and icon for their site; … … 34 36 - Refactor parts of Trac so that different environments can be supported. 35 37 36 37 == Proposed Solution == 38 == Proposed Solution 38 39 39 40 - OBSOLETE? A new trac-portal-admin console will be introduced for setting up / administering a portal instance; … … 45 46 - A new trac.portal.api Portlet 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; 46 47 47 - 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. ..48 - 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. 48 49 49 50 - A new <portlet.../> Genshi directive will be introduced for authoring the portal template; 50 51 51 - TBD 52 53 54 == GUI Mockups == 52 == GUI Mockups 55 53 56 54 TBD 57 55 58 59 == Initial Set of Portlets == 56 == Initial Set of Portlets 60 57 61 58 - !SearchPortlet -- allows one to search across all projects under the reign of the portal … … 73 70 - TBD 74 71 75 76 == Initial Set of Portal Modules == 72 == Initial Set of Portal Modules 77 73 78 74 - TBD.portal.prefs -- replaces the preferences for all of the projects reigned by the portal; … … 84 80 - TBD 85 81 86 87 == Portal Template == 82 == Portal Template 88 83 89 84 Portal templates are genshi templates, however, the portal system will register a new directive prior to rendering the template. This new directive is the <portlet.../> directive. 90 85 91 === Sample Portal Template ===86 === Sample Portal Template 92 87 93 88 {{{ … … 136 131 }}} 137 132 138 == Discussion of Design Decisions Made ==133 == Discussion of Design Decisions Made 139 134 140 135 - 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;
