[xwiki-devs] [Discussion] Dashboard default behaviour
Hi devs, I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do? 1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc). 2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document. WDYT? There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing: A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document) B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard) C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users. E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home"). F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition). If you can think of more cases that could involve include issues, please fill them in. Thanks, Anca
On 15.02.2011 16:44, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
I need to mention that the current implementation is 2/ -- which satisfies very well the usecase A. below -- but it's not too much in the spirit of the {{include}}, since it implements context=new behaviour for gadgets reading, although the include macro is using the current context. Thanks, Anca
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Feb 15, 2011 at 16:44, Anca Luca <lucaa@xwiki.com> wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
My take is that the default should be to use the including document as the default source (solution 1/). If users want another document to be the source, they can specify it manually. Rationale: it's the easiest to understand / less cognitive demanding behavior (I put the dashboard macro on page A, it gets data from page A). As an user, if I add a dashboard on a page and I can't see where it takes data from right away even though I didn't specify a source, I will feel lost. So it feels natural to me to have behavior 1/ and it's in the spirit of how the include macro works by default. Guillaume WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 15.02.2011 16:54, Guillaume Lerouge wrote:
Hi,
On Tue, Feb 15, 2011 at 16:44, Anca Luca<lucaa@xwiki.com> wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
My take is that the default should be to use the including document as the default source (solution 1/). If users want another document to be the source, they can specify it manually.
Rationale: it's the easiest to understand / less cognitive demanding behavior (I put the dashboard macro on page A, it gets data from page A). As an user, if I add a dashboard on a page and I can't see where it takes data from right away even though I didn't specify a source, I will feel lost. So it feels natural to me to have behavior 1/ and it's in the spirit of how the include macro works by default.
Obviously if you put {{dashboard /}} on page A it will take data from page A. The question is, what should happen when you include page A in page B. Say page B has as content: {{include document="A" /}} Where should the dashboard defined in page A take objects from when page B is rendered? solution 1/ means it would be from document B, unless it's {{include document="A" context="new" /}}. If you want to be able to include dashboard defined in the document A as is in a document B, you'll have some options: a. you include with context="new" but that means if some stuff in document A is using $doc, $doc will be A, and not B -- for example will not work with the current Main.Dashboard included in main webhome and space webhomes, which uses $doc to figure out if it's on the Main.WebHome or a space dashboard. b. in page A, instead of {{dashboard /}} you write {{dashboard source="A" /}} but this makes it really bad when you want to copy document A (because document name will change but not the dashboard param) -- usecase C is a little in this spirit c. in page B, if all you care about is the dashboard and not the rest of the stuff, you write {{dashboard source="A" /}} instead of {{include document="A" /}} -- see usecase F. solution 2/ means it would be from document A. Thanks, Anca
Guillaume
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Feb 15, 2011, at 4:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
+1 for 1/ + an optional source param, which handles all use cases listed below AFAICS. For the Main.WebHome, we'll need to decide if we want that dashboard to be the same for everyone or customizable. If customizable then we'll have source=$context.getUser(). That said we'll need to provide a default dashboard too so maybe we'll need to show a default dashboard and have a customize button and when clicked it would copy the default dashboard's objects to the user's page or something like that... So the algo could be something like: {{velocity}} if current user has dashboard objects then use source="current user ref" else don't specify a source (ie use objects on the Dashboard page - since it's included from the Main.WebHome page). {{/velocity}} Thanks -Vincent
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca
On 15.02.2011 17:37, Vincent Massol wrote:
On Feb 15, 2011, at 4:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
+1 for 1/ + an optional source param, which handles all use cases listed below AFAICS.
For the Main.WebHome, we'll need to decide if we want that dashboard to be the same for everyone or customizable. If customizable then we'll have source=$context.getUser().
There's 2 levels of customizable: * customizable as in each user with his own dashboard * customizable as in it can be modified by one user, all users see the changes, but the changes only impact Main.WebHome and not all the space WebHomes. Which basically means that when a user changes the Main.WebHome, it must not modify Main.Dashboard, but something else, like the Main.WebHome page itself. Which further means that Main.WebHome by default should contain the gadget objects, not include Main.Dashboard. Either that or we implement right away the "copy on customize" mechanism, but I prefer a simpler solution ftm, since I don't think this can fit in M3. Same for any kind of customization mechanism other than editing the dashboard document, it won't fit in M3.
That said we'll need to provide a default dashboard too so maybe we'll need to show a default dashboard and have a customize button and when clicked it would copy the default dashboard's objects to the user's page or something like that...
So the algo could be something like:
{{velocity}} if current user has dashboard objects then use source="current user ref" else don't specify a source (ie use objects on the Dashboard page - since it's included from the Main.WebHome page). {{/velocity}}
This would be the algo for what? Main.WebHome? I don't understand the else branch very well... "use objects on the Dashboard page - since it's included from the Main.WebHome page" doesn't make too much sense: if a source is not specified, the documents in the current page will be used upon include. If it's included from the Main.WebHome, it will use the objects on the Main.WebHome page. Thanks, Anca
Thanks -Vincent
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 02/15/2011 04:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
Also note that solution 1/ with a source parameter to the dashboard macro to allow dashboard reusage breaks the backwards compatibility of Main.Dashboard, since the default include that was used until now {{include document="Main.Dashboard" /}} now tries to find the gadget objects in the current document, not in the Main.Dashboard. It will need to be changed to {{dashboard source="Main.Dashboard" /}} (according to usecase F about reusing dashboards). WDYT? Thanks, Anca
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 02/16/2011 04:46 PM, Anca Luca wrote:
On 02/15/2011 04:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
Also note that solution 1/ with a source parameter to the dashboard macro to allow dashboard reusage breaks the backwards compatibility of Main.Dashboard, since the default include that was used until now {{include document="Main.Dashboard" /}} now tries to find the gadget objects in the current document, not in the Main.Dashboard. It will need to be changed to {{dashboard source="Main.Dashboard" /}} (according to usecase F about reusing dashboards).
This can be an issue for the space webhomes of all existing applications, which need to be modified, if we want to preserve behaviour.
WDYT?
Thanks, Anca
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On 02/16/2011 04:46 PM, Anca Luca wrote:
On 02/15/2011 04:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including doc).
Also note that solution 1/ with a source parameter to the dashboard macro to allow dashboard reusage breaks the backwards compatibility of Main.Dashboard, since the default include that was used until now {{include document="Main.Dashboard" /}} now tries to find the gadget objects in the current document, not in the Main.Dashboard. It will need to be changed to {{dashboard source="Main.Dashboard" /}} (according to usecase F about reusing dashboards).
Another solution is to keep Main.Dashboard as a regular page, not a dashboard, so that it can be included, and implement real dashboards for the Main.WebHome, either stored in the document itself, or in some other general purpose reusable dashboard, such as Main.Dashboard2. But then users using the wiki and going to "wiki dashboard" will not be able to edit it as a dashboard, which doesn't make too much sense. Also, I don't see which other document we could create as a wiki dashboard, with a name that makes sense. Obviously, Main.Dashboard2 is not even close to a decent choice. WDYT? Thanks, Anca
WDYT?
Thanks, Anca
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Wed, Feb 16, 2011 at 18:55, Anca Luca <lucaa@xwiki.com> wrote:
On 02/16/2011 04:46 PM, Anca Luca wrote:
On 02/15/2011 04:44 PM, Anca Luca wrote:
Hi devs,
I committed XWIKI-5938 but I think we should discuss the default source of the dashboard macro, namely where does it pick the gadget objects to display on the dashboard, e.g. in the case of a dashboard macro call in an included document. It is very easy to add a "source" parameter to the dashboard macro, which would tell the dashboard where should it read the objects from (and render in the context of the current document), but now the question is what should {{dashboard /}} without parameters do?
1/ read the objects from the current document, which means, in the case of an include, it will depend on the context of the include. Note that, if an include is done in a new context, then all the gadgets on that dashboard will be also relative to the included document (e.g. if they use $doc, the $doc will be the included document, not the including
doc).
Also note that solution 1/ with a source parameter to the dashboard macro to allow dashboard reusage breaks the backwards compatibility of Main.Dashboard, since the default include that was used until now {{include document="Main.Dashboard" /}} now tries to find the gadget objects in the current document, not in the Main.Dashboard. It will need to be changed to {{dashboard source="Main.Dashboard" /}} (according to usecase F about reusing dashboards).
Another solution is to keep Main.Dashboard as a regular page, not a dashboard, so that it can be included, and implement real dashboards for the Main.WebHome, either stored in the document itself, or in some other general purpose reusable dashboard, such as Main.Dashboard2.
But then users using the wiki and going to "wiki dashboard" will not be
able to edit it as a dashboard, which doesn't make too much sense. Also, I don't see which other document we could create as a wiki dashboard, with a name that makes sense. Obviously, Main.Dashboard2 is not even close to a decent choice.
WDYT?
Not implementing the wiki dashboard as an actual dashboard doesn't really make sense to me either. It's better to find a solution to make it work as a regular dashboard. If we have no choice but to break backward compatibility, XE 3.0 is a good time to do so. Guillaume Thanks,
Anca
WDYT?
Thanks, Anca
2/ read the objects from the closest MetaData.SOURCE, which means the document from which the content that contains the {{dashboard /}} call comes from. E.g. in the case of an include, the included document.
WDYT?
There are a lot of possible situations to discuss, I will just present a few usecases below, to be taken into account when analyzing:
A. The current Main.Dashboard is included in all the WebHomes by default, but its gadgets refer to the current document (the _including_ document)
B. Users want to be able to easily customize their WebHomes, without affecting other people (not change the wiki general dashboard, but only their space dashboard)
C. There is a dashboard somewhere on the wiki, Main.CoolDashboard, and users want to be able to include that dashboard as a copy, without having to re-create the dashboard objects on their including page
D. User dashboards: at one point we will want each user to have their own dashboard on their profile page, which is rendered by a sheet. Ideally we should have the same user sheet for all users.
E. Also, the user dashboard should be include-able on the Main.WebHome of a logged in user (a "Home").
F. Since the include doesn't make too much sense for a dashboard document (since the dashboard document is only a call to a {{dashboard /}} macro), users will replace its usage with {{dashboard /}} macro calls, with a source parameter to pick gadget objects from another document ('reuse' a dashboard definition).
If you can think of more cases that could involve include issues, please fill them in.
Thanks, Anca _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Anca Luca -
Guillaume Lerouge -
Vincent Massol