On 15 Oct 2015 at 11:12:42, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:
> 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/ContentElemens.png > http://design.xwiki.org/xwiki/bin/download/Improvements/PageAdministration/ContentHistory.png > > 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. I’m not sure Caty. As I replied in some other mail, I’m -0 ATM till we have a way to turn it on easily for some users. Let’s see what others say. Thanks -Vincent > Thanks, > Caty > > On Thu, Oct 15, 2015 at 10:41 AM, [email protected] > wrote: > > > Hi, > > > > On 15 Oct 2015 at 09:10:36, Guillaume Lerouge ([email protected](mailto: > > [email protected])) 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/ApplicationDevelopmentBestPractices > > > > > > > > > > Thanks, > > > > > Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
