Re: [xwiki-devs] [Proposal] Removing comments, attachments, etc. tabs (#docextra) in default applications WebHome

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 http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration Images: http://design.xwiki.org/xwiki/bin/download/Improvements/PageAdministration/… http://design.xwiki.org/xwiki/bin/download/Improvements/PageAdministration/… Until we implement http://jira.xwiki.org/browse/XWIKI-12497 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 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