Hi,
Thanks Vincent for providing implementation ideas.
The "Page metadata visibility" options should be part of the "Page
Administration".
There is an older proposal for this
and since we
are planning to provide backwards compatibility support I plan to fix this
issue now by using the velocity variable $docextra.
Thanks,
Caty
On Thu, Oct 15, 2015 at 10:41 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi,
On 15 Oct 2015 at 09:10:36, Guillaume Lerouge (guillaume(a)xwiki.com(mailto:
guillaume(a)xwiki.com)) wrote:
Hi,
I agree with Paul on this. To me, it could work a bit like the "hidden
doc"
checkmark. We can show it only for advanced users
and/or admins if
needed.
Since there are plenty of use cases and they depend on the wiki and the
condition could be as complex as can imagine, I’d do it like this:
* Add a new XObject to control the display of the docextra tab and its
elements. This XObject should have 2 properties:
** One being a multi-select Select to choose the tabs to hide (Comments,
History, etc)
** The other being a textarea property where we can put script and if this
script evaluates to true (some variable is set to true) then hide the
selected items from the Select.
* For backward-compatibility we should continue to honor the velocity
variables
* We should also continue to offer space-level settings (Page Elements
option in the Admin UI), see
https://www.evernote.com/l/AHd7c8OU6edOd7rBKqIqXpxzFweaMV4LzM0 but we
should also refactor it to use a multi-select Select instead to make it
easier to decide to display none or all of the tabs.
Alternative 1:
* Instead of an XObject, put this inside the Page-level Administration
(the 2 fields) and also add the script field for Space-level admin for
consistency
Alternative 2:
* Instead of having 2 xproperties in the XObject only have a single script
field and set the docextra velocity variables in there (based on some
conditions if we want).
Alternative 3:
* Add a radio group xproperty in the XObject for predefined behavior (if
the script xproperty is filled then it takes precedence). I can think of 2
predefined values in the radio group:
** “Always hide”
** “Hide for Simple Users"
The current practice, which implies putting a
{{velocity}} tag with
docextra = [] on each home page feels a bit antiquated…
As mentioned above, note that we have a UI, see
https://www.evernote.com/l/AHd7c8OU6edOd7rBKqIqXpxzFweaMV4LzM0
WDYT?
Thanks
-Vincent
As for the list itself, it looks good to me as
well.
Thanks,
Guillaume
On Wed, Oct 14, 2015 at 9:55 PM, Paul Libbrecht wrote:
> Would it make sense, in this case, to make a checkbox that is displayed
> to admins in case the docextra tab is hidden?
> (maybe this would edit a webpreferences object?)
>
> It seems to me that the desire to hide the docextra tab is for any page
> that displays some kind of summary: you'd expect the docextra function
> on "data pages" not on "summary pages"; i suppose this is likely
to be
> the case of many other pages.
>
> Paul
>
> > Ecaterina Moraru (Valica)
> > 14 octobre 2015 19:19
> > Hi,
> >
> > #docextra tabs are particular important for content pages where
users
are
> > encouraged to comment, attach, revise
history, etc.
> >
> > But since XWiki is more than a wiki and the application usage has
> > expanded,
> > we removed the #docextra tab from many XWiki Contrib applications,
like:
> > File Manager, Forum, Calendar, etc.
> >
> > The logic behind was that the applications have as main purpose the
> > management of applications entities, not commenting for example.
> >
> > Also with the Flamingo Skin, the shortcuts to Comments, Attachments,
etc.
> > can be found in the 'More
actions' menu.
> >
> > So, my question to you is: What do you think about removing the
#docextra
> > also for default/bundled applications
like:
> > - Blog.WebHome
> > - Dashboard.WebHome
> > - Panels.WebHome
> > - Scheduler.WebHome
> > - Stats.WebHome
> > - Main.WebHome?
> >
> > If we adopt this practice we could document it on:
> >
http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HApplicationDesign
> or
> >
>
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…
> >
> > Thanks,
> > Caty
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs