While it would be nice to have some sort of single main portal page that people could use as a landing point, and that would perhaps show different things based on permissions they have so that adapts better to specific roles, the portal/portlet features can be quite a bit more.
As for "My Portal" versus "Dashboard" I'd prefer to stick with the term "My Portal". The problem I see with Dashboard is that it is used in the world of BI and reporting to represent something rather different, and something that is mostly for monitoring the status of various metrics, usually including charts and graphs and such. Of course it would be cool to have screenlets that do present information using chart/graphs/whatever and those could be included in portal pages.
The way I think of a "portal" page is that they are just configurable screens, and I was tempted to propose we rename them as such, but in a way I like the addition to the confusion surrounding the term "portal" (which is a mess right now anyway, but seem to mean something in a generic way and this seems consistent with that).
As a configurable screen in addition to having a single landing page of sorts (ie the My Portal page) we could also have various configurable screens that start out with a certain configuration but that can be changed by users. Some examples that have come to mind:
1. the main page of the catalog manager with it's various parts, or even just the left bar of the catalog manager that is there in a few of the top-level tabs
2. landing pages in any role-oriented application: the projectmgr app targets multiple roles so may have multiple ones, others like the sfa webapp are targeted more at a single role and so would have a landing page meant just for that role
3. various pages in different applications that could be left open to customization, even the Party Manager profile page and any page that has multiple sections like that
-David On Dec 22, 2008, at 6:12 AM, Bruno Busco wrote:
Hi devs, IMO we are proceeding really well with Hans's MyPortal application that uses the Portal/Portlet feature. We have recently considered, and more or less agreed, that portlets will be defined in the base or derived applications. Using this pattern, base (and derived) components should never be aware of more high level and "aggregative" application like MyPortal. In my original thought there was only one "aggregative" application (the Dashboard) embedded in the framework. Embedding the Dashboard in the framework was possible just thanks to the independence of the "aggregative" application from the portlets that is guarranteed by the Portal/Portlet mechanism. I imagined that, in this way, the framework embedded Dashboard could even be used like a "home" application where users could land when they enter the OFBiz. With this "framework-centric" pattern, the MyPortal application could have been a simple application that defines some portlets (and related) and does not define an own application tab and screens. Yust rely on the framework Dashboard. So, summarizing, I propose: 1) To move all portlet definitions to their related applications (mainly partymgr and projectmgr) 2) Have MyPortal only define its own portlets (and all related stuff) 3) Remove MyPortal Application tab 4) Have a Dashboard Application tab that works as home also What do you think about? -Bruno
