22 Nov
2010
22 Nov
'10
2:48 p.m.
On Mon, Nov 22, 2010 at 2:13 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
On 11/22/2010 02:03 PM, Anca Luca wrote:
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs