+1 Regards, Sorin B. On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

+1

On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

I'd like to introduce a Dashboard Application in a xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module.

It would contain the following pages:

1/ Main.Dashboard.xml (currently in XE's app) 2/ The pages making up the user dashboard (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) (currently in Admin app) 3/ A new page which will have the logic to choose to display the user dashboard or the main shared dashboard (currently this code is in Main.WebHome in XE's app)

Also I'd like to suggest introducing a Dashboard space and have all the above-mentioned pages in that space.

Dashboard.WebHome would contain 3/.

And Main.WebHome would simply do an include of Dashboard.WebHome.

Note that this would allow the following: * Ability to cleanly document the Dashboard feature on extensions.xwiki.org and have it visible on enterprise.xwiki.org for example * It goes in the direction of splitting our XE XAR in discrete application * It groups together (functionally) a domain (dashboard) which means that if a user doesn't want the dashboard feature, we can simply not install it or remove it easily.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

+1, Also, what about the Dashboard macro itself? Can it be moved inside something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro? Thus, we would also have something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui for the xwiki pages. This would organize it more like a feature. WDYT? Thanks, Eduard On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

+1

On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

I'd like to introduce a Dashboard Application in a xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module.

It would contain the following pages:

1/ Main.Dashboard.xml (currently in XE's app) 2/ The pages making up the user dashboard (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) (currently in Admin app) 3/ A new page which will have the logic to choose to display the user dashboard or the main shared dashboard (currently this code is in Main.WebHome in XE's app)

Also I'd like to suggest introducing a Dashboard space and have all the above-mentioned pages in that space.

Dashboard.WebHome would contain 3/.

And Main.WebHome would simply do an include of Dashboard.WebHome.

Note that this would allow the following: * Ability to cleanly document the Dashboard feature on extensions.xwiki.org and have it visible on enterprise.xwiki.org for example * It goes in the direction of splitting our XE XAR in discrete application * It groups together (functionally) a domain (dashboard) which means that if a user doesn't want the dashboard feature, we can simply not install it or remove it easily.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 11/14/2011 01:51 PM, Vincent Massol wrote:

On Nov 14, 2011, at 1:41 PM, Eduard Moraru wrote:

...

+1,

Also, what about the Dashboard macro itself? Can it be moved inside something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro? It's a wiki macro. I wouldn't create a new app just for it. IMO it's very fine in the Dashboard app and would be overkill to create a new app just for 1 page (I also don't see what it would bring more).

? dashboard macro is not a 'wiki macro' as in it's not in a wiki page, it's in a java module. It would make a bit sense to move it in it's own module since it's a bit of a rebel macro: it uses and depends on the platform-oldcore which is not really what rendering macros do... Otherwise I have nothing against putting all that in a dashboard application ( 0 ), as long as it's preserving the behaviour. Just as an experience to share: upgrading Main.WebHome is really really annoying, on multiwikis, we need to make a script or so everytime we make changes in the default main.webhome, so in this case too. I gained this experience when i changed the main.webhome in order to introduce dashboards on it, and everybody that upgraded farms complained about having to upgrade each main.webhome manually. We should avoid this. Thanks, Anca

Thanks -Vincent

...

Thus, we would also have something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui for the xwiki pages. This would organize it more like a feature.

WDYT?

Thanks, Eduard

On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

...

+1

On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol<[email protected]> wrote:

...

Hi devs,

I'd like to introduce a Dashboard Application in a xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module. It would contain the following pages:

1/ Main.Dashboard.xml (currently in XE's app) 2/ The pages making up the user dashboard (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) (currently in Admin app) 3/ A new page which will have the logic to choose to display the user dashboard or the main shared dashboard (currently this code is in Main.WebHome in XE's app) Also I'd like to suggest introducing a Dashboard space and have all the above-mentioned pages in that space. Dashboard.WebHome would contain 3/.

And Main.WebHome would simply do an include of Dashboard.WebHome.

Note that this would allow the following: * Ability to cleanly document the Dashboard feature on extensions.xwiki.org and have it visible on enterprise.xwiki.org for example * It goes in the direction of splitting our XE XAR in discrete application * It groups together (functionally) a domain (dashboard) which means that if a user doesn't want the dashboard feature, we can simply not install it or remove it easily. WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 11/14/2011 02:32 PM, Vincent Massol wrote:

On Nov 14, 2011, at 2:28 PM, Anca Luca wrote:

...

On 11/14/2011 01:51 PM, Vincent Massol wrote:

...

On Nov 14, 2011, at 1:41 PM, Eduard Moraru wrote:

...

+1,

Also, what about the Dashboard macro itself? Can it be moved inside something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro? It's a wiki macro. I wouldn't create a new app just for it. IMO it's very fine in the Dashboard app and would be overkill to create a new app just for 1 page (I also don't see what it would bring more). ?

dashboard macro is not a 'wiki macro' as in it's not in a wiki page, it's in a java module. It would make a bit sense to move it in it's own module since it's a bit of a rebel macro: it uses and depends on the platform-oldcore which is not really what rendering macros do… My bad. I mixed it with the activity macro.

Indeed it's not a wiki macro and I completely agree with Eddy's suggestion :)

...

Otherwise I have nothing against putting all that in a dashboard application ( 0 ), as long as it's preserving the behaviour.

Just as an experience to share: upgrading Main.WebHome is really really annoying, on multiwikis, we need to make a script or so everytime we make changes in the default main.webhome, so in this case too. I gained this experience when i changed the main.webhome in order to introduce dashboards on it, and everybody that upgraded farms complained about having to upgrade each main.webhome manually. We should avoid this. Actually someone upgrading will see have its Main.Dashboard page present unless we removes it. So it should be fine.

I don't understand. What does Main.Dashboard have to do with Main.WebHome? since some version (3.2-m-something), Main.WebHome is a standalone dashboard, it's not using Main.Dashboard, it has and uses its own dashboard (gadgets are stored in the page itself). It only uses Main.Welcome to grab the welcome text which needs to be translated in all languages so we put it in a separate page. I'm talking about the fact that if Main.WebHome changes code (and it will since you plan to remove the user dashboard logic from it), you need to have an automated way of updating all the main.webhome s on a farm.

However I agree that it would be great to have some wiki migrators.

Do you have a suggestion?

I don't know, i would need to look at some code (to see how other migration works, etc). From my pov, I think even a script on extensions. xwiki.org could do the job, which just upgrades all main.webhomes or gives some checkboxes for the user to select which one, I don't know. I cannot really answer this question now. Anca

Thanks -Vincent

...

Thanks, Anca

...

Thanks -Vincent

...

Thus, we would also have something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui for the xwiki pages. This would organize it more like a feature.

WDYT?

Thanks, Eduard

On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

...

+1

On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol<[email protected]> wrote:

...

Hi devs,

I'd like to introduce a Dashboard Application in a xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module. It would contain the following pages:

1/ Main.Dashboard.xml (currently in XE's app) 2/ The pages making up the user dashboard (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) (currently in Admin app) 3/ A new page which will have the logic to choose to display the user dashboard or the main shared dashboard (currently this code is in Main.WebHome in XE's app) Also I'd like to suggest introducing a Dashboard space and have all the above-mentioned pages in that space. Dashboard.WebHome would contain 3/.

And Main.WebHome would simply do an include of Dashboard.WebHome.

Note that this would allow the following: * Ability to cleanly document the Dashboard feature on extensions.xwiki.org and have it visible on enterprise.xwiki.org for example * It goes in the direction of splitting our XE XAR in discrete application * It groups together (functionally) a domain (dashboard) which means that if a user doesn't want the dashboard feature, we can simply not install it or remove it easily. WDYT?

Thanks -Vincent

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 11/14/2011 03:49 PM, Vincent Massol wrote:

Hi devs/Anca,

On Nov 14, 2011, at 3:24 PM, Anca Luca wrote:

...

On 11/14/2011 02:32 PM, Vincent Massol wrote:

...

On Nov 14, 2011, at 2:28 PM, Anca Luca wrote:

...

On 11/14/2011 01:51 PM, Vincent Massol wrote:

...

On Nov 14, 2011, at 1:41 PM, Eduard Moraru wrote:

...

+1,

Also, what about the Dashboard macro itself? Can it be moved inside something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro? It's a wiki macro. I wouldn't create a new app just for it. IMO it's very fine in the Dashboard app and would be overkill to create a new app just for 1 page (I also don't see what it would bring more). ?

dashboard macro is not a 'wiki macro' as in it's not in a wiki page, it's in a java module. It would make a bit sense to move it in it's own module since it's a bit of a rebel macro: it uses and depends on the platform-oldcore which is not really what rendering macros do… My bad. I mixed it with the activity macro.

Indeed it's not a wiki macro and I completely agree with Eddy's suggestion :)

...

Otherwise I have nothing against putting all that in a dashboard application ( 0 ), as long as it's preserving the behaviour.

Just as an experience to share: upgrading Main.WebHome is really really annoying, on multiwikis, we need to make a script or so everytime we make changes in the default main.webhome, so in this case too. I gained this experience when i changed the main.webhome in order to introduce dashboards on it, and everybody that upgraded farms complained about having to upgrade each main.webhome manually. We should avoid this. Actually someone upgrading will see have its Main.Dashboard page present unless we removes it. So it should be fine. I don't understand. What does Main.Dashboard have to do with Main.WebHome? since some version (3.2-m-something), Main.WebHome is a standalone dashboard, it's not using Main.Dashboard, it has and uses its own dashboard (gadgets are stored in the page itself). It only uses Main.Welcome to grab the welcome text which needs to be translated in all languages so we put it in a separate page. My idea is the following:

* Have a Dashboard.WebHome page which displays the "main" dashboard which could be either the wiki dashboard or the user dashboard * Have Quick Links Panel 's Dashboard link to point to Dashboard.WebHome * Have Main.WebHome's content to be {{include document="Dashboard.WebHome" context="new"/}}

My rationale is that: * we should have a place in the wiki to display the "main" dashboard and have a link to it from the UI (this is the Quick Links Panel + The Dashboard space which would now appear in the list of spaces) * it just happens that we want by default the Main.WebHome to display the "main" dashboard but an admin/user might want to display something else and having a single include with no gadgets in it makes it easy to do * If users want to create a space dashboard they'd simply use {{dashboard/}} for their space (and later on they'd use a space template for example) * I find it a bit strange right now that we have 2 "official" dashboards: the Main.WebHome one and the Main.Dashboard one

it's the same rationale: Main.Dashboard is the official wiki dashboard, Main.WebHome just happens to be a dashboard (it could be anything else). I think we chose this approach (a different dashboard instead of an include) for the same reason, to allow the main.webhome to be changed while the official wiki dashboard still stays as a dashboard. And an include was sort of technically hard to do because we wanted to keep Main.Dashboard as a something that can be used by the space dashboards, if we decide to break this behaviour (and I think we could since creating a dashboard in the space webhome is not that hard + we should provide a template rather than a page to include) it will be easier to have an unique wiki db which is used on main.webhome.

(it's official because the Quick Links Panel points to it). I think one is good enough by default. Actually I think that the current Main.Dashboard is probably more a Space Template Dashboard, which we could keep in Dashboard, as Dashboard.DashboardTemplate for example if we want to keep it (not sure it's needed at this stage though).

WDYT?

Sounds pretty decent to me, provided that we find a proper way to make sure that if users edit Main.WebHome as a dashboard, they are aware that they're changing the wiki dashboard (impacting the wiki dashboard which is linked from the quick links). Thanks, Anca

Thanks -Vincent

...

I'm talking about the fact that if Main.WebHome changes code (and it will since you plan to remove the user dashboard logic from it), you need to have an automated way of updating all the main.webhome s on a farm.

...

However I agree that it would be great to have some wiki migrators.

Do you have a suggestion? I don't know, i would need to look at some code (to see how other migration works, etc). From my pov, I think even a script on extensions. xwiki.org could do the job, which just upgrades all main.webhomes or gives some checkboxes for the user to select which one, I don't know. I cannot really answer this question now.

Anca

...

Thanks -Vincent

...

Thanks, Anca

...

Thanks -Vincent

...

Thus, we would also have something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui for the xwiki pages. This would organize it more like a feature.

WDYT?

Thanks, Eduard

On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

> +1 > > On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol<[email protected]> > wrote: >> Hi devs, >> >> I'd like to introduce a Dashboard Application in a > xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module. >> It would contain the following pages: >> >> 1/ Main.Dashboard.xml (currently in XE's app) >> 2/ The pages making up the user dashboard > (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) > (currently in Admin app) >> 3/ A new page which will have the logic to choose to display the user > dashboard or the main shared dashboard (currently this code is in > Main.WebHome in XE's app) >> Also I'd like to suggest introducing a Dashboard space and have all the > above-mentioned pages in that space. >> Dashboard.WebHome would contain 3/. >> >> And Main.WebHome would simply do an include of Dashboard.WebHome. >> >> Note that this would allow the following: >> * Ability to cleanly document the Dashboard feature on > extensions.xwiki.org and have it visible on enterprise.xwiki.org for > example >> * It goes in the direction of splitting our XE XAR in discrete > application >> * It groups together (functionally) a domain (dashboard) which means > that if a user doesn't want the dashboard feature, we can simply not > install it or remove it easily. >> WDYT? >> >> Thanks >> -Vincent

On 11/15/2011 12:19 PM, Vincent Massol wrote:

On Nov 15, 2011, at 12:03 PM, Anca Luca wrote:

...

On 11/14/2011 03:49 PM, Vincent Massol wrote:

...

Hi devs/Anca,

On Nov 14, 2011, at 3:24 PM, Anca Luca wrote:

...

On 11/14/2011 02:32 PM, Vincent Massol wrote:

...

On Nov 14, 2011, at 2:28 PM, Anca Luca wrote:

...

On 11/14/2011 01:51 PM, Vincent Massol wrote: > On Nov 14, 2011, at 1:41 PM, Eduard Moraru wrote: > >> +1, >> >> Also, what about the Dashboard macro itself? Can it be moved inside >> something like >> xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro? > It's a wiki macro. I wouldn't create a new app just for it. IMO it's very fine in the Dashboard app and would be overkill to create a new app just for 1 page (I also don't see what it would bring more). ?

dashboard macro is not a 'wiki macro' as in it's not in a wiki page, it's in a java module. It would make a bit sense to move it in it's own module since it's a bit of a rebel macro: it uses and depends on the platform-oldcore which is not really what rendering macros do… My bad. I mixed it with the activity macro.

Indeed it's not a wiki macro and I completely agree with Eddy's suggestion :)

...

Otherwise I have nothing against putting all that in a dashboard application ( 0 ), as long as it's preserving the behaviour.

Just as an experience to share: upgrading Main.WebHome is really really annoying, on multiwikis, we need to make a script or so everytime we make changes in the default main.webhome, so in this case too. I gained this experience when i changed the main.webhome in order to introduce dashboards on it, and everybody that upgraded farms complained about having to upgrade each main.webhome manually. We should avoid this. Actually someone upgrading will see have its Main.Dashboard page present unless we removes it. So it should be fine. I don't understand. What does Main.Dashboard have to do with Main.WebHome? since some version (3.2-m-something), Main.WebHome is a standalone dashboard, it's not using Main.Dashboard, it has and uses its own dashboard (gadgets are stored in the page itself). It only uses Main.Welcome to grab the welcome text which needs to be translated in all languages so we put it in a separate page. My idea is the following:

* Have a Dashboard.WebHome page which displays the "main" dashboard which could be either the wiki dashboard or the user dashboard * Have Quick Links Panel 's Dashboard link to point to Dashboard.WebHome * Have Main.WebHome's content to be {{include document="Dashboard.WebHome" context="new"/}}

My rationale is that: * we should have a place in the wiki to display the "main" dashboard and have a link to it from the UI (this is the Quick Links Panel + The Dashboard space which would now appear in the list of spaces) * it just happens that we want by default the Main.WebHome to display the "main" dashboard but an admin/user might want to display something else and having a single include with no gadgets in it makes it easy to do * If users want to create a space dashboard they'd simply use {{dashboard/}} for their space (and later on they'd use a space template for example) * I find it a bit strange right now that we have 2 "official" dashboards: the Main.WebHome one and the Main.Dashboard one it's the same rationale: Main.Dashboard is the official wiki dashboard, Main.WebHome just happens to be a dashboard (it could be anything else). I think we chose this approach (a different dashboard instead of an include) for the same reason, to allow the main.webhome to be changed while the official wiki dashboard still stays as a dashboard. And an include was sort of technically hard to do because we wanted to keep Main.Dashboard as a something that can be used by the space dashboards, if we decide to break this behaviour (and I think we could since creating a dashboard in the space webhome is not that hard + we should provide a template rather than a page to include) it will be easier to have an unique wiki db which is used on main.webhome. I have committed a Dashboard.DashboardTemplate page which ATM you can use as a space dashboard with:

{{dashboard source="Dashboard.DashboardTemplate"/}}

Actually if I get the time (and if we agree) I could create a page template for creating a Dashboard Page based on it, although I think this template should only have a single widget explaining what the user should do to edit and customize his dashboard.

there is an issue open about this, I had started to do it, but I didn't finish. It's planned, exactly with this strategy. The pb that I had was the i18n of this gadget with instructions.

The DashboardTemplate page could be renamed to SpaceDashboardTemplate instead and used manually for now (with {{dashboard source="Dashboard.SpaceDashboardTemplate"/}} and as a space template later on when we get this feature).

should be renamed in the first version, I think. Thanks, Anca

...

...

(it's official because the Quick Links Panel points to it). I think one is good enough by default. Actually I think that the current Main.Dashboard is probably more a Space Template Dashboard, which we could keep in Dashboard, as Dashboard.DashboardTemplate for example if we want to keep it (not sure it's needed at this stage though).

WDYT? Sounds pretty decent to me, provided that we find a proper way to make sure that if users edit Main.WebHome as a dashboard, they are aware that they're changing the wiki dashboard (impacting the wiki dashboard which is linked from the quick links). The way I've solved this is by making Main.WebHome a standard page, i.e when you edit it you get to see the WYSIWYG editor like for any page. If you edit the macro in it you're going to edit the include macro. And there's a link in the side panel showing that Dashboard.Panel is an included document and you can click on it and edit the dashboard there.

Thanks -Vincent

...

Thanks, Anca

...

Thanks -Vincent

...

I'm talking about the fact that if Main.WebHome changes code (and it will since you plan to remove the user dashboard logic from it), you need to have an automated way of updating all the main.webhome s on a farm.

...

However I agree that it would be great to have some wiki migrators.

Do you have a suggestion? I don't know, i would need to look at some code (to see how other migration works, etc). From my pov, I think even a script on extensions. xwiki.org could do the job, which just upgrades all main.webhomes or gives some checkboxes for the user to select which one, I don't know. I cannot really answer this question now.

Anca

...

Thanks -Vincent

...

Thanks, Anca

> Thanks > -Vincent > >> Thus, we would also have something like >> xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui >> for the xwiki pages. This would organize it more like a feature. >> >> WDYT? >> >> Thanks, >> Eduard >> >> On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> +1 >>> >>> On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol<[email protected]> >>> wrote: >>>> Hi devs, >>>> >>>> I'd like to introduce a Dashboard Application in a >>> xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module. >>>> It would contain the following pages: >>>> >>>> 1/ Main.Dashboard.xml (currently in XE's app) >>>> 2/ The pages making up the user dashboard >>> (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) >>> (currently in Admin app) >>>> 3/ A new page which will have the logic to choose to display the user >>> dashboard or the main shared dashboard (currently this code is in >>> Main.WebHome in XE's app) >>>> Also I'd like to suggest introducing a Dashboard space and have all the >>> above-mentioned pages in that space. >>>> Dashboard.WebHome would contain 3/. >>>> >>>> And Main.WebHome would simply do an include of Dashboard.WebHome. >>>> >>>> Note that this would allow the following: >>>> * Ability to cleanly document the Dashboard feature on >>> extensions.xwiki.org and have it visible on enterprise.xwiki.org for >>> example >>>> * It goes in the direction of splitting our XE XAR in discrete >>> application >>>> * It groups together (functionally) a domain (dashboard) which means >>> that if a user doesn't want the dashboard feature, we can simply not >>> install it or remove it easily. >>>> WDYT? >>>> >>>> Thanks >>>> -Vincent

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Mon, Nov 14, 2011 at 1:41 PM, Eduard Moraru <[email protected]> wrote:

+1,

Also, what about the Dashboard macro itself? Can it be moved inside something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-macro?

Thus, we would also have something like xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/xwiki-platform-dashboard-ui for the xwiki pages. This would organize it more like a feature.

WDYT?

+1

Thanks, Eduard

On Mon, Nov 14, 2011 at 1:18 PM, Thomas Mortagne <[email protected]>wrote:

...

+1

On Mon, Nov 14, 2011 at 11:23 AM, Vincent Massol <[email protected]> wrote:

...

Hi devs,

I'd like to introduce a Dashboard Application in a xwiki-platform/xwiki-platform-core/xwiki-platform-dashboard/ module.

It would contain the following pages:

1/ Main.Dashboard.xml (currently in XE's app) 2/ The pages making up the user dashboard (XWiki.UserDashboardPreferencesClass, XWiki.XWikiUserDashboardSheet) (currently in Admin app) 3/ A new page which will have the logic to choose to display the user dashboard or the main shared dashboard (currently this code is in Main.WebHome in XE's app)

Also I'd like to suggest introducing a Dashboard space and have all the above-mentioned pages in that space.

Dashboard.WebHome would contain 3/.

And Main.WebHome would simply do an include of Dashboard.WebHome.

Note that this would allow the following: * Ability to cleanly document the Dashboard feature on extensions.xwiki.org and have it visible on enterprise.xwiki.org for example * It goes in the direction of splitting our XE XAR in discrete application * It groups together (functionally) a domain (dashboard) which means that if a user doesn't want the dashboard feature, we can simply not install it or remove it easily.

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne