Discussion: MyPortal vs. framework dashboard

[Bruno Busco]

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

[David E Jones-3]

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

[hans_bakker]

Hi Bruno,

First of all i think this development is a nice example of community
collaboration. Started with the MyPage development, then the portal
functions and in the end merging everything together and I expect it
will not stop there.

I expect that these portal functions will be used in many places in
OFBiz. Not only as a framework dashboard, but also as a logged-on user
oriented MyPortal component and more. Wouldn't it be nice to have every
'overview' page being configurable like the party profile page? Most
people are only interested in certain screenlets of that page and
certainly not at all, the same is true for the invoice overview, payment
overview, project overview, quote overview etc etc....

The next thing we can think about is the starting 'main' page of every
component. This page should give you the current status of the data in
that component. Also here it is impossible to have a 'one page fits all'
version. A user should be able to modify that.

So i see the portal functions useful in many places....... so not
'MyPortal vs. framework dashboard' but your 'framework portal/portlet
functions' being used in many places....

Regards,
Hans


--
Antwebsystems.com: Quality OFBiz services for competitive prices

[Bruno Busco]

Many thanks David and Hans for your feedbacks.
Of course for "vs." I did not mean "against". I am more than happy
with this collaborating experience.

What I meant was:
In a framework-only release (which I am now working on) it could be
cool to have a "home" page where the user lands when it logs in. This
could be mounted to "/" and could be just a PortalPage with some
framework-defined portlets.

If we agree on this, we could also think that the "home" page, in a
full OFBiz installation, could be the same but simply hosting more
(application-defined) portlets, still mounted on "/".

Now, in this scenario, what will be the difference between the
MyPortal application and this application-powered-up "home" portal?

I hope that now, with this explanation, the reason why I see an
overlapping between MyPortal and a framework home is more clear.

I perfectly agree with the pattern we are outlining (portals in every
main application screen or everywhere needed). I think it is very
important to focus it so that future development will be done
according to it (hopefully ;-) )

Can I summarize like this what we are going to do ?

1) Since we are going to have many Configurable screens we should
think to define a Decorator for this.
2) Framework should define a "home" application mounted (by default)
on "/". This application is just a one configurable screen (Portal).
3) Every (or almost) application main page should be a configurable
screen and the actual main page content should be redefined as
portlets.

Do you agree?

-Bruno


2008/12/23 Hans Bakker <[hidden email]>:

> Hi Bruno,
>
> First of all i think this development is a nice example of community
> collaboration. Started with the MyPage development, then the portal
> functions and in the end merging everything together and I expect it
> will not stop there.
>
> I expect that these portal functions will be used in many places in
> OFBiz. Not only as a framework dashboard, but also as a logged-on user
> oriented MyPortal component and more. Wouldn't it be nice to have every
> 'overview' page being configurable like the party profile page? Most
> people are only interested in certain screenlets of that page and
> certainly not at all, the same is true for the invoice overview, payment
> overview, project overview, quote overview etc etc....
>
> The next thing we can think about is the starting 'main' page of every
> component. This page should give you the current status of the data in
> that component. Also here it is impossible to have a 'one page fits all'
> version. A user should be able to modify that.
>
> So i see the portal functions useful in many places....... so not
> 'MyPortal vs. framework dashboard' but your 'framework portal/portlet
> functions' being used in many places....
>
> Regards,
> Hans
>
>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>
>

[hans_bakker]

Hi Bruno,

currently the framework and the ERP application on top of it, have
different target audiences and users.

The example component is a showcase of the framework and the myPortal
component is a special component showing specific portalpages  with
specific portlets for the specific kind of users of the ERP application.
So software developers vs ERP users...

I would like to suggest to keep it as it is now: the example component
for the framework and the MyPortal for the ERP application.

Regards,
Hans

On Tue, 2008-12-23 at 09:45 +0100, Bruno Busco wrote:

> Many thanks David and Hans for your feedbacks.
> Of course for "vs." I did not mean "against". I am more than happy
> with this collaborating experience.
>
> What I meant was:
> In a framework-only release (which I am now working on) it could be
> cool to have a "home" page where the user lands when it logs in. This
> could be mounted to "/" and could be just a PortalPage with some
> framework-defined portlets.
>
> If we agree on this, we could also think that the "home" page, in a
> full OFBiz installation, could be the same but simply hosting more
> (application-defined) portlets, still mounted on "/".
>
> Now, in this scenario, what will be the difference between the
> MyPortal application and this application-powered-up "home" portal?
>
> I hope that now, with this explanation, the reason why I see an
> overlapping between MyPortal and a framework home is more clear.
>
> I perfectly agree with the pattern we are outlining (portals in every
> main application screen or everywhere needed). I think it is very
> important to focus it so that future development will be done
> according to it (hopefully ;-) )
>
> Can I summarize like this what we are going to do ?
>
> 1) Since we are going to have many Configurable screens we should
> think to define a Decorator for this.
> 2) Framework should define a "home" application mounted (by default)
> on "/". This application is just a one configurable screen (Portal).
> 3) Every (or almost) application main page should be a configurable
> screen and the actual main page content should be redefined as
> portlets.
>
> Do you agree?
>
> -Bruno
>
>
> 2008/12/23 Hans Bakker <[hidden email]>:
> > Hi Bruno,
> >
> > First of all i think this development is a nice example of community
> > collaboration. Started with the MyPage development, then the portal
> > functions and in the end merging everything together and I expect it
> > will not stop there.
> >
> > I expect that these portal functions will be used in many places in
> > OFBiz. Not only as a framework dashboard, but also as a logged-on user
> > oriented MyPortal component and more. Wouldn't it be nice to have every
> > 'overview' page being configurable like the party profile page? Most
> > people are only interested in certain screenlets of that page and
> > certainly not at all, the same is true for the invoice overview, payment
> > overview, project overview, quote overview etc etc....
> >
> > The next thing we can think about is the starting 'main' page of every
> > component. This page should give you the current status of the data in
> > that component. Also here it is impossible to have a 'one page fits all'
> > version. A user should be able to modify that.
> >
> > So i see the portal functions useful in many places....... so not
> > 'MyPortal vs. framework dashboard' but your 'framework portal/portlet
> > functions' being used in many places....
> >
> > Regards,
> > Hans
> >
> >
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive prices
> >
> >

--
Antwebsystems.com: Quality OFBiz services for competitive prices