[xwiki-devs] Should Main.Spaces/Main.Activity be hidden by default?
Hi, I think it should since it's the page that serves to define the {{spaces/}} macro. Similar question for the Main.Activity page which defines the {{activity/}} macro. If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default. Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them. WDYT? Thanks -Vincent
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page. So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden. Do you agree? If we're careful that should allow us to only return meaningful results in searches for users by default. Thanks -Vincent
On Jun 24, 2013, at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page.
So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden.
Do you agree?
If we're careful that should allow us to only return meaningful results in searches for users by default.
I've started listing pages I'd like to make "hidden" by default: http://jira.xwiki.org/browse/XWIKI-9263 Thanks -Vincent
+1 On Mon, Jun 24, 2013 at 9:07 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the
{{spaces/}} macro.
Similar question for the Main.Activity page which defines the
{{activity/}} macro.
If we want to have those pages used by the user as "features", then I
think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden
since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page.
So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden.
Do you agree?
If we're careful that should allow us to only return meaningful results in searches for users by default.
I've started listing pages I'd like to make "hidden" by default: http://jira.xwiki.org/browse/XWIKI-9263
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
I've committed http://jira.xwiki.org/browse/XWIKI-9263 and http://jira.xwiki.org/browse/XE-1307 just now (I wanted to have them in 5.1RC1). Please let me know if it's an issue and I'll rollback. Thanks -Vincent On Jun 24, 2013, at 9:07 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page.
So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden.
Do you agree?
If we're careful that should allow us to only return meaningful results in searches for users by default.
I've started listing pages I'd like to make "hidden" by default: http://jira.xwiki.org/browse/XWIKI-9263
Thanks -Vincent
I don't agree with this non-content based rule. For me hidden pages are pages you are not supposed to go to and even if entry point pages are mostly dynamic page without real content it's not right to hide them. On Mon, Jun 24, 2013 at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page.
So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden.
Do you agree?
If we're careful that should allow us to only return meaningful results in searches for users by default.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Jun 26, 2013 at 4:48 PM, Thomas Mortagne <[email protected]> wrote:
I don't agree with this non-content based rule. For me hidden pages are pages you are not supposed to go to and even if entry point pages are mostly dynamic page without real content it's not right to hide them.
I kind of agree with Thomas here. I voted +1 for Main.Spaces and Main.Activity because a simple user doesn't use them directly. But I'm not sure about the blog home page. As I commented on http://jira.xwiki.org/browse/XWIKI-9263 , hiding the a page that serves as parent for content pages makes those content pages invisible in the XWiki Explorer tree, which prevent users from creating links to those content pages. Thanks, Marius
On Mon, Jun 24, 2013 at 8:50 PM, Vincent Massol <[email protected]> wrote:
On Jun 24, 2013, at 8:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
BTW Main.UserDirectory is marked hidden even though it's the home page of an app (the user directory app) and listed in the Applications panel. This is fine with me since it's not a content page.
So the rule is probably that non content pages should be marked "hidden" by default and thus Main.Spaces and Main.Activity should be marked hidden.
Do you agree?
If we're careful that should allow us to only return meaningful results in searches for users by default.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Marius On Mon, Jun 24, 2013 at 9:46 PM, Vincent Massol <[email protected]> wrote:
Hi,
I think it should since it's the page that serves to define the {{spaces/}} macro.
Similar question for the Main.Activity page which defines the {{activity/}} macro.
If we want to have those pages used by the user as "features", then I think we should separate the pages: have one page for the macro definition and another page for using the macro. One reason is that we don't want technical code to be returned by default in searches for example and if we have a separate page for the macro then we can mark it hidden and it won't be returned by default in searches. I think we need to hunt for all pages that return code by default.
Personally I think that Main.Spaces and Main.Activity should be hidden since there's no navigation leading to them.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol