[xwiki-devs] [discussion] Global and space dashboards implementation
Hi devs, ** short story: ** for XE-722 we'd need to implement the main and spaces dashboards separately ** long story: ** currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards. With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard). ** options: ** 1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general 2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though. Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability. I'd +1 for 1) and I'd choose 2c). WDYT? Thanks a lot, Anca
On 11/22/2010 02:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this.
Also, there is another option here: 3) leave everything as it is, but implement all the scoping in the gadgets (tagcloud, spaces, activity macros): 2a) and if the current space is Main, act like a global wiki. I personally don't like this solution since too much logic is included in the macros on the dashboard, it's too magical, macros should make sense standalone and they make less sense with all this functionality embedded. Think in particular of the top left gadget which lists the spaces for the global dashboard and the list of documents for a space dashboard: we'd need to detect the case and return the right content in a single macro. Thanks, Anca
Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 11/22/2010 03:13 PM, Anca Luca wrote:
On 11/22/2010 02:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this.
Also, there is another option here:
3) leave everything as it is, but implement all the scoping in the gadgets (tagcloud, spaces, activity macros): 2a) and if the current space is Main, act like a global wiki.
like a global dashboard, that is.
I personally don't like this solution since too much logic is included in the macros on the dashboard, it's too magical, macros should make sense standalone and they make less sense with all this functionality embedded. Think in particular of the top left gadget which lists the spaces for the global dashboard and the list of documents for a space dashboard: we'd need to detect the case and return the right content in a single macro.
Thanks, Anca
Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca _______________________________________________ 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 Mon, Nov 22, 2010 at 2:13 PM, Anca Luca <[email protected]> wrote:
On 11/22/2010 02:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited). Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document. The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this.
Also, there is another option here:
3) leave everything as it is, but implement all the scoping in the gadgets (tagcloud, spaces, activity macros): 2a) and if the current space is Main, act like a global wiki.
I personally don't like this solution since too much logic is included in the macros on the dashboard, it's too magical, macros should make sense standalone and they make less sense with all this functionality embedded. Think in particular of the top left gadget which lists the spaces for the global dashboard and the list of documents for a space dashboard: we'd need to detect the case and return the right content in a single macro.
Thanks, Anca
Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that
capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
I would be -1 to remove Main.Dashboard, at least for now. We need it to be backward compatible, including for space dashboards. That said, it does not mean we have to use it on the home page (Main.WebHome), we can indeed do it directly using the dashboard macro. Also, Main.Dashboard can use the dashboard macro + scripting. (Thus, we don't need to have a scope parameter when it does not make sense, like space list vs. document list, we just script Main.Dashboard to use different macros according to the context). Jerome.
Thanks a lot, Anca _______________________________________________ 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 Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example. Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro. I need more info about my questions above to answer the points below. Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about: {{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}} How would you ever be able to re-produce that piece of wiki syntax from an HTML?
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument. however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language. Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit. Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard. 2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content. With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example). ... just a wild idea... ;) Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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/23/2010 09:05 AM, Vincent Massol wrote:
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit.
How would you render {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} without the velocity transformation? Note that you edit the macro content, not the macro output, so the macro (velocity) transformation must be excluded (because the transformation is applied on the macro content to generate the macro output). Thanks, Marius
Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard. 2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content.
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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/23/2010 09:05 AM, Vincent Massol wrote:
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
this would be solution no 3) which I don't like that much, because it would make the gadgets inside too aware of the fact that they are part of a dashboard.
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit.
Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard.
lemme remember (and dig in the mails) why we didn't like this solution. It was a proposed solution in the design document which we've discussed at one point http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration .
2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content.
this is the part which cannot work, because even if I produce the modified XDOM, how would I ever be able to produce the velocity code that would generate that modified XDOM to re-produce the wiki syntax? Think about: {{velocity wiki=true}} {{dashboard}} ((( #if($isSpaceDashboard) {{spaceindex /}} #else {{spaces /}} #end ))) {{/dashboard}} {{/velocity}} which is very similar to what we'd have on the Main.Dashboard. Thanks, Anca
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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/23/2010 11:52 AM, Anca Luca wrote:
On 11/23/2010 09:05 AM, Vincent Massol wrote:
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
this would be solution no 3) which I don't like that much, because it would make the gadgets inside too aware of the fact that they are part of a dashboard.
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit.
Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard.
lemme remember (and dig in the mails) why we didn't like this solution. It was a proposed solution in the design document which we've discussed at one point http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration .
Actually, even if it's a great solution for editing (and now I am looking for why we didn't like it), it will not fix anything on the scripting side: if you put objects in a page and the dashboard macro only gathers them and displays them, all you'd be able to do in velocity would be: {{velocity}} {{dashboard source="Main.Dashboard" /}} {{/velocity}} but the example below (from my previous mail), with conditional display of gadgets depending on some conditions in velocity, will still not be possible. However, I would like to think more about storing gadgets in objects because it could make editing a lot easier... Or not, I just thought, I don't know how to store the gadget instance parameters in a structured manner, if we want to store all the gadget objects in the same page, and storing them in different pages will be an overkill (I was just thinking with my fingers on the keyboard, you can skip this part). Thanks, Anca
2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content.
this is the part which cannot work, because even if I produce the modified XDOM, how would I ever be able to produce the velocity code that would generate that modified XDOM to re-produce the wiki syntax? Think about:
{{velocity wiki=true}} {{dashboard}} ((( #if($isSpaceDashboard) {{spaceindex /}} #else {{spaces /}} #end ))) {{/dashboard}} {{/velocity}}
which is very similar to what we'd have on the Main.Dashboard.
Thanks, Anca
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 11/23/2010 01:07 PM, Anca Luca wrote:
On 11/23/2010 11:52 AM, Anca Luca wrote:
On 11/23/2010 09:05 AM, Vincent Massol wrote:
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
this would be solution no 3) which I don't like that much, because it would make the gadgets inside too aware of the fact that they are part of a dashboard.
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit.
Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard.
lemme remember (and dig in the mails) why we didn't like this solution. It was a proposed solution in the design document which we've discussed at one point http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration .
Actually, even if it's a great solution for editing (and now I am looking for why we didn't like it), it will not fix anything on the scripting side: if you put objects in a page and the dashboard macro only gathers them and displays them, all you'd be able to do in velocity would be:
{{velocity}} {{dashboard source="Main.Dashboard" /}} {{/velocity}}
but the example below (from my previous mail), with conditional display of gadgets depending on some conditions in velocity, will still not be possible.
However, I would like to think more about storing gadgets in objects because it could make editing a lot easier... Or not, I just thought, I don't know how to store the gadget instance parameters in a structured manner, if we want to store all the gadget objects in the same page, and storing them in different pages will be an overkill (I was just thinking with my fingers on the keyboard, you can skip this part).
Actually, it is possible to store parameters, in objects, just like wikimacro parameters in macros definitions (gadget id, parameter name, parameter value). What I wouldn't know how to do, is complex layouting: for example having a 2 columns dashboard and a column which, at one point, splits in two: with wiki macros is simple, we just use the container macro. By storing the gadgets in objects, I don't know what kind of information to store about the gadget position to make that layouting possible. Any ideas about this, anyone? Anyone remembers why we liked the macro instances inside a dashboard macro more than storing the gadgets in an object in a page? For the moment I still like the macros idea more than objects, because it's a little easier to understand (type this content in your page and you'll have a dashboard), it's more semantic for the layouting, and it uses macros directly as gadgets, without going through aditional data structures. However it's more difficult to edit (see http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration#HImplementation the **edit mode** part) than gadgets stored as objects in the page. WDYT about this? Thanks, Anca
Thanks, Anca
2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content.
this is the part which cannot work, because even if I produce the modified XDOM, how would I ever be able to produce the velocity code that would generate that modified XDOM to re-produce the wiki syntax? Think about:
{{velocity wiki=true}} {{dashboard}} ((( #if($isSpaceDashboard) {{spaceindex /}} #else {{spaces /}} #end ))) {{/dashboard}} {{/velocity}}
which is very similar to what we'd have on the Main.Dashboard.
Thanks, Anca
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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
_______________________________________________ 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 Tue, Nov 23, 2010 at 08:05, Vincent Massol <[email protected]> wrote:
On Nov 23, 2010, at 12:18 AM, Anca Luca wrote:
On 11/22/2010 03:34 PM, Vincent Massol wrote:
On Nov 22, 2010, at 1:03 PM, Anca Luca wrote:
Hi devs,
** short story: **
for XE-722 we'd need to implement the main and spaces dashboards separately
** long story: **
currently we're using the Main.Dashboard page to include in various contexts to create a dashboard (global or space level). Namely, it is used in Main.WebHome (to create the global dashboard) and in all the *.WebHome pages to create the space dashboards.
With the implementation of the dashboard macro, now there is a simpler (and better) way to create dashboards, but with a restriction, they should not be generated by a velocity script (because something which is generated programatically cannot be wysiwyg edited).
Why is there velocity script around the dashboard macro?
if you mean on the Main.Dashboard, it's because you need to detect whether it's a global dashboard or a space dashboard, and pass the parameters with the current space to the activity and tagcloud macros.
I thought there was a discussion about using a scope parameter suggested by jerome (but I don't know if we concluded about it or not in the end).
Because of this, the Main.Dashboard cannot be used anymore as is (since it needs velocity to differentiate between space or global dashboard).
Note that this is a wysiwyg limitation that we need to fix over time anyway.
If it's about wysiwyg editing the generated stuff, I don't think we can ever fix it. I mean dashboard wysiwyg (drag and drop gadgets to set positions, click a button to edit parameters, etc). Think about:
{{velocity wiki=true}} {{dashboard}} #set($column = "{{spaces /}}") ((($column))) {{/dashboard}} {{/velocity}}
How would you ever be able to re-produce that piece of wiki syntax from an HTML?
It's easy. The wysiwyg sees the velocity macro and since wiki=true the content is wiki and thus the wysiwyg would allow you to edit the content in wysiwyg mode, thus seeing visually the dashboard macro which you can click on and edit.
No it's not easy, velocity macro does not contains something you can parse with a wiki parser, it contains velocity which generates something you can parse with wiki parser eventually.
Now I've just realized that you may not be talking about the wysiwyg editor but simply about click on edit in the dashboard in view mode. I guess that's solvable too with several strategies: 1) store the dashboard macro cells/columns in a Dashboard Object on the page. When editing it it's those objects that are changed. This makes it very easy to modify a dashboard. 2) or navigate the XDOM tree to find the dashboard macro and change the order of the columns/cells according to how the user has moved them around or how he added new content.
With solution 1) you'd start by creating an empty dashboard, then go in edit mode and add content. Adding content would create DashboardItem objects (for example).
... just a wild idea... ;)
Thanks -Vincent
** options: **
1) have the dashboard macro directly in the Main.WebHome and not in an included document.
I don't like this too much. We need a Main.Dashboard page IMO since users will want to customize their home page I think and still have a link to the Dashboard page in the quick links menu for example.
ok, I agree with this argument.
however, this might be an issue in conjunction with Jerome's arguments for keeping Main.Dashboard as space dashboard for compatibility reasons (which I agree with), since we might need to implement 3) (see my cons for proposal 3).
Let's say I'm 0 on this.
The bad part is that when a translation is edited, it's only that translation which sees the changes, but this is an issue in general
I don't get this part. This is true whether you have an {{include}} or a {{dashboard}} macro.
which is what I said above, but I was just wondering whether it's a bigger problem for main webhome dashboard than it is in general. Because that's the standard type of content that is displayed on the main webhome and one might think that one customization should be done regardless of the language.
Thanks, Anca
I need more info about my questions above to answer the points below.
Thanks -Vincent
2) for the space dashboards, there are 3 possibilities: a) leave it all in the Main.Dashboard document to be included in all space dashboards ('backwards compatible') b) leave it all in a document to be included but rename it to Main.SpaceDashboard (to be semantic) c) remove any document for this purpose, and write the dashboard macro call directly in the space webhome, since now it should be a lot easier to do that and also to customize it (7-8 lines of code but no wysiwyg, yet), potentially create a template provider for this. Note that a) and b) require a way for the recent activity and tagcloud macros to realize that it's the current space they need to use as the scope, without actually passing the space because that would mean velocity scripting, again. This is not necessarily a bad thing, though.
Besides overcoming this, c) has also the advantage that the dashboard will be in the document itself, and not included (I don't have yet a straightforward solution for wysiwyg editing included dashboards). The drawback of c) is that it will be impossible to customize all the space dashboard at once, you'd need to develop a bit to provide that capability.
I'd +1 for 1) and I'd choose 2c).
WDYT?
Thanks a lot, Anca
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
-- Thomas Mortagne
participants (5)
-
Anca Luca -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol