[Proposal] Removing comments, attachments, etc. tabs (#docextra) in default applications WebHome

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Removing comments, attachments, etc. tabs (#docextra) in default applications WebHome

Ecaterina Moraru (Valica)
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Paul Libbrecht-2
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) <mailto:[hidden email]>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Guillaume Lerouge
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.
The current practice, which implies putting a {{velocity}} tag with
docextra = [] on each home page feels a bit antiquated...

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 <[hidden email]> 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) <mailto:[hidden email]>
> > 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
Hi,

On 15 Oct 2015 at 09:10:36, Guillaume Lerouge ([hidden email](mailto:[hidden email])) 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
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.

Thanks,
Caty

On Thu, Oct 15, 2015 at 10:41 AM, [hidden email] <[hidden email]>
wrote:

> Hi,
>
> On 15 Oct 2015 at 09:10:36, Guillaume Lerouge ([hidden email](mailto:
> [hidden email])) 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)

On 14 Oct 2015 at 19:19:26, Ecaterina Moraru (Valica) ([hidden email](mailto:[hidden email])) wrote:

> 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

Maybe not just the home but also other pages such as Blog.ManageCategories.

> - Dashboard.WebHome
> - Panels.WebHome
> - Scheduler.WebHome
> - Stats.WebHome
> - Main.WebHome?

I’m not sure about Main.WebHome.

Note that I’m -0 ATM. I’m not thrilled, especially if there’s no way to turn if on/off easily by some category of users.

Thanks
-Vincent

> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)

On 15 Oct 2015 at 11:12:42, Ecaterina Moraru (Valica) ([hidden email](mailto:[hidden email])) 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, [hidden email]  
> wrote:
>  
> > Hi,
> >
> > On 15 Oct 2015 at 09:10:36, Guillaume Lerouge ([hidden email](mailto:
> > [hidden email])) 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Ecaterina Moraru (Valica)
In reply to this post by vmassol
On Thu, Oct 15, 2015 at 12:20 PM, [hidden email] <[hidden email]>
wrote:

>
> On 14 Oct 2015 at 19:19:26, Ecaterina Moraru (Valica) ([hidden email]
> (mailto:[hidden email])) wrote:
>
> > 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
>
> Maybe not just the home but also other pages such as Blog.ManageCategories.
>

This proposal was about WebHomes for now. Of course if we plan to go deep
into other types of pages (like Blog.ManageCategories that can we extend to
remove the docextra for all technical pages) we will need the UI for it.

Thanks,
Caty


>
> > - Dashboard.WebHome
> > - Panels.WebHome
> > - Scheduler.WebHome
> > - Stats.WebHome
> > - Main.WebHome?
>
> I’m not sure about Main.WebHome.
>
> Note that I’m -0 ATM. I’m not thrilled, especially if there’s no way to
> turn if on/off easily by some category of users.
>
> Thanks
> -Vincent
>
> > 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
In reply to this post by vmassol
AFAIR, usecases like these (together with rights management) were the
reason why most of us agreed that page administration is a good thing to
have, in addition to the existing space administration. They might be a bit
cosmeticized now with NS/ND, but the idea should remain the same (2 admin
sections, 1 for space and 1 for individual page that overrides the space
settings). That is at least for the presentational level.

On the implementation side (actually, still mostly talking in functionality
terms), I would (ideally) view this as more or less of a skin customization
section, where the skin is pretty much a collection of extension points. In
this case, it would mean filtering the #docextra extension point, defined
by the #docextra UIX inserted in the #afterContent UIXP that is defined by
the skin's layout. More generally speaking, we should be able to control if
a particular UIX will be displayed on the current page/space/wiki by
specifying some velocity script that would return true/false, as Vincent
suggested. All of this should be seen as configuration, even if the rules
are bits of code. Back to our example, we need to be able to set a rule for
the #docextra UIX.

I know it's a bit far fetched from our current state, but IMO until we
reach a level where skins are defined as collections of extension points
and configurations of UIX/UIXPs, we will struggle each time we introduce a
new skin and each time we have a particular skin problem for which we will
introduce a new custom mechanism to keep track of and maintain. A skin
editor with a palette of UIXP/UIX to drag&drop from + the ability to
generically override the skin's configuration at various levels in the page
hierarchy would be pretty awesome.

Now, back to the real world, probably the simplest would be to display a
new option (e.g. "Show Page Extra Sections") in this list
https://www.evernote.com/shard/s119/sh/7b73c394-e9e7-4e77-bac1-2aa22a5e9c73/17079a315e0bcccd
under Page Administration.

Thanks,
Eduard

On Thu, Oct 15, 2015 at 10:41 AM, [hidden email] <[hidden email]>
wrote:

> Hi,
>
> On 15 Oct 2015 at 09:10:36, Guillaume Lerouge ([hidden email](mailto:
> [hidden email])) 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs