17 Feb
2011
17 Feb
'11
11:07 a.m.
Hi,
On Wed, Feb 16, 2011 at 18:55, Anca Luca <lucaa(a)xwiki.com> wrote:
On 02/16/2011 04:46 PM, Anca Luca wrote:
But then users using the wiki and going to "wiki dashboard" will not be
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. 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs