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
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
