[xwiki-devs] [VOTE] Add a children section in page footer
Hi devs, There are 4 votes required, see bellow. 1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files. Here's my +1 2/ Add a getChildren() method to XWikiDocument and Document (API). Rationale: XWiki is a wiki and the parent/child relationship should be made more visible and easy to display in order to make it useful. I know we should try not to put new methods in our APIs but IMHO this should have been there from the beginning. Proposal: {{code}} Document.java public List<String> getChildren() throws XWikiException { return this.doc.getChildren(getXWikiContext()); } XWikiDocument.java public List<String> getChildren(XWikiContext context) throws XWikiException { String hql ="select doc.fullName from XWikiDocument doc " + "where doc.parent='" + getFullName() + "' order by doc.space, doc.name"; return context.getWiki().search(hql, context); } {{/code}} Note: I've put doc.space and doc.name in the order by clause since getting pages in the 'absolute' alphabetical order afterwards is easy using util.sort while the contrary is not true. Here's my +1 3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid duplicates; this list is already present in some panels and pages since it is a common need. Proposal: #set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats", "XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"]) Here's my +1 4/ Don't display the number of children in tab. Rationale: limit the number of HQL queries made on the view action. Here's my +1 Thanks, JV.
On Tue, Jan 20, 2009 at 11:33 AM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
XWikiDocument.java
public List<String> getChildren(XWikiContext context) throws XWikiException { String hql ="select doc.fullName from XWikiDocument doc " + "where doc.parent='" + getFullName() + "' order by doc.space, doc.name"; return context.getWiki().search(hql, context); } {{/code}}
Note: I've put doc.space and doc.name in the order by clause since getting pages in the 'absolute' alphabetical order afterwards is easy using util.sort while the contrary is not true.
Note: I must be tired, ordering by doc.fullName will work just the same, sorry for the noise. So the only question is do we put an order by clause here or do we rely on util.sort. +1 for keeping an order by clause.
On Tue, Jan 20, 2009 at 11:33 AM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1
2/ Add a getChildren() method to XWikiDocument and Document (API). Rationale: XWiki is a wiki and the parent/child relationship should be made more visible and easy to display in order to make it useful. I know we should try not to put new methods in our APIs but IMHO this should have been there from the beginning.
Proposal:
{{code}} Document.java
public List<String> getChildren() throws XWikiException { return this.doc.getChildren(getXWikiContext()); }
XWikiDocument.java
public List<String> getChildren(XWikiContext context) throws XWikiException { String hql ="select doc.fullName from XWikiDocument doc " + "where doc.parent='" + getFullName() + "' order by doc.space, doc.name"; return context.getWiki().search(hql, context); } {{/code}}
Note: I've put doc.space and doc.name in the order by clause since getting pages in the 'absolute' alphabetical order afterwards is easy using util.sort while the contrary is not true.
Here's my +1
+1 for ordering (on fullname directly in place of space and name as Jean-Vincent suggested)
3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid duplicates; this list is already present in some panels and pages since it is a common need.
Proposal: #set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats", "XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"])
Here's my +1
+1 for now but would be better to have general support for hidden space ultimately (like we have for hidden documents).
4/ Don't display the number of children in tab. Rationale: limit the number of HQL queries made on the view action.
Here's my +1
+1
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, Jan 20, 2009 at 4:03 PM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1 Say, if I open Main.WebHome and there are 1000 documents in Main space, would it lists all the docs?
2/ Add a getChildren() method to XWikiDocument and Document (API). Rationale: XWiki is a wiki and the parent/child relationship should be made more visible and easy to display in order to make it useful. I know we should try not to put new methods in our APIs but IMHO this should have been there from the beginning.
Proposal:
{{code}} Document.java
public List<String> getChildren() throws XWikiException { return this.doc.getChildren(getXWikiContext()); }
XWikiDocument.java
public List<String> getChildren(XWikiContext context) throws XWikiException { String hql ="select doc.fullName from XWikiDocument doc " + "where doc.parent='" + getFullName() + "' order by doc.space, doc.name"; return context.getWiki().search(hql, context); } {{/code}}
Note: I've put doc.space and doc.name in the order by clause since getting pages in the 'absolute' alphabetical order afterwards is easy using util.sort while the contrary is not true.
Here's my +1
+1.
3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid duplicates; this list is already present in some panels and pages since it is a common need.
Proposal: #set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats", "XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"])
Here's my +1
+0 (not familiar)
4/ Don't display the number of children in tab. Rationale: limit the number of HQL queries made on the view action.
Here's my +1
+0 (not familiar) Thanks. - Asiri
Thanks, JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Jan 20, 2009 at 11:50 AM, Asiri Rathnayake <[email protected]> wrote:
On Tue, Jan 20, 2009 at 4:03 PM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1
Say, if I open Main.WebHome and there are 1000 documents in Main space, would it lists all the docs?
Fortunately no :) This list only represent parent/child relationship, when you create PageB from PageA (with a wiki link): PageA is the parent and PageB the child. This relationships create a tree within and between spaces, you can see the whole tree with Index>Treeview in XE. JV.
On Tue, Jan 20, 2009 at 4:25 PM, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Jan 20, 2009 at 11:50 AM, Asiri Rathnayake <[email protected]> wrote:
On Tue, Jan 20, 2009 at 4:03 PM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1
Say, if I open Main.WebHome and there are 1000 documents in Main space, would it lists all the docs?
Fortunately no :) This list only represent parent/child relationship, when you create PageB from PageA (with a wiki link): PageA is the parent and PageB the child.
Sorry, i meant in cases where Main.WebHome is the parent of all the other pages in Main space. Basically, is there a limit to the number of children displayed? Thanks. - Asiri
This relationships create a tree within and between spaces, you can see the whole tree with Index>Treeview in XE.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Jan 20, 2009 at 11:59 AM, Asiri Rathnayake < [email protected]> wrote:
On Tue, Jan 20, 2009 at 4:25 PM, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Jan 20, 2009 at 11:50 AM, Asiri Rathnayake <[email protected]> wrote:
On Tue, Jan 20, 2009 at 4:03 PM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1
+1 as well. 1) Is the children information better located in a separate tab or under the Information tab? That might overload the information tab itself. The information tab gives information about the current page, the children tab is more of a navigation tool. However we could consider moving the parent page to the the same tab as the list of children. Both options are acceptable to me. 2) Shouldn't we reuse our upcoming Treeview component for implementing the children information. We could make that Treeview component take a base document and display all children of that base document. If the user has edit rights then he would be allowed to drag and drop Treeview nodes around, reorganizing child pages directly. What we could do in the future is to create a Parents & Children tab that uses the treeview to dislay the page, its parent and its children (so only level n+1 & N-1). A sort of local navigation map of the current page ("page immediate relatives"). In the meanwhile, this is an improvement to what we already have thus it's worth adding it. 3) Are we not starting to have too many tabs? (hence question 1) above). This is an open question. I don't know the answer. I don't think we have too many tabs. Each of them provide specific bits of information. It's easy for users to ignore them but if they're looking for specific bits of information about the page they know they'll find it here. Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
On Jan 20, 2009, at 12:33 PM, Guillaume Lerouge wrote:
Hi,
On Tue, Jan 20, 2009 at 11:59 AM, Asiri Rathnayake < [email protected]> wrote:
On Tue, Jan 20, 2009 at 4:25 PM, Jean-Vincent Drean <[email protected]>wrote:
On Tue, Jan 20, 2009 at 11:50 AM, Asiri Rathnayake <[email protected]> wrote:
On Tue, Jan 20, 2009 at 4:03 PM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
+1
+1 as well.
1) Is the children information better located in a separate tab or under the Information tab?
That might overload the information tab itself. The information tab gives information about the current page, the children tab is more of a navigation tool. However we could consider moving the parent page to the the same tab as the list of children. Both options are acceptable to me.
2) Shouldn't we reuse our upcoming Treeview component for implementing the children information. We could make that Treeview component take a base document and display all children of that base document. If the user has edit rights then he would be allowed to drag and drop Treeview nodes around, reorganizing child pages directly.
What we could do in the future is to create a Parents & Children tab that uses the treeview to dislay the page, its parent and its children (so only level n+1 & N-1). A sort of local navigation map of the current page ("page immediate relatives").
In the meanwhile, this is an improvement to what we already have thus it's worth adding it.
We must deliver a working Treeview for 1.8M2 so I 'm not sure we have time to do both and it would be really a pity to do both and need to refactor afterwards... -Vincent
3) Are we not starting to have too many tabs? (hence question 1) above). This is an open question. I don't know the answer.
I don't think we have too many tabs. Each of them provide specific bits of information. It's easy for users to ignore them but if they're looking for specific bits of information about the page they know they'll find it here.
Guillaume
On Tue, Jan 20, 2009 at 11:33 AM, Jean-Vincent Drean <[email protected]> wrote:
Hi devs,
3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid duplicates; this list is already present in some panels and pages since it is a common need.
Proposal: #set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats", "XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"])
Here's my +1
Addendum: the best way to achieve this would be to implement the notion of hidden space in XWiki (for example with a boolean prop 'hidden' in the XWiki.XWikiPreferences class), this proposal is a minor improvement to our current way of doing it.
Hi, On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
Three questions: 1) Is the children information better located in a separate tab or under the Information tab? 2) Shouldn't we reuse our upcoming Treeview component for implementing the children information. We could make that Treeview component take a base document and display all children of that base document. If the user has edit rights then he would be allowed to drag and drop Treeview nodes around, reorganizing child pages directly. 3) Are we not starting to have too many tabs? (hence question 1) above). This is an open question. I don't know the answer. Otherwise +1 in general.
2/ Add a getChildren() method to XWikiDocument and Document (API). Rationale: XWiki is a wiki and the parent/child relationship should be made more visible and easy to display in order to make it useful. I know we should try not to put new methods in our APIs but IMHO this should have been there from the beginning.
Proposal:
{{code}} Document.java
public List<String> getChildren() throws XWikiException { return this.doc.getChildren(getXWikiContext()); }
XWikiDocument.java
public List<String> getChildren(XWikiContext context) throws XWikiException { String hql ="select doc.fullName from XWikiDocument doc " + "where doc.parent='" + getFullName() + "' order by doc.space, doc.name"; return context.getWiki().search(hql, context); } {{/code}}
Note: I've put doc.space and doc.name in the order by clause since getting pages in the 'absolute' alphabetical order afterwards is easy using util.sort while the contrary is not true.
Here's my +1
+1
3/ Add a $blacklistedSpaces list in xwikivars.vm. Rationale: avoid duplicates; this list is already present in some panels and pages since it is a common need.
Proposal: #set($blacklistedSpaces = ["Import", "Panels", "Scheduler", "Stats", "XAppClasses", "XAppSheets", "XAppTemplates", "XWiki"])
Here's my +1
Wouldn't it be better to implement this as Sergiu has started doing for pages (hidden documents). We could decide that if the WebHome for a space is hidden then the whole space is hidden for example.
4/ Don't display the number of children in tab. Rationale: limit the number of HQL queries made on the view action.
Here's my +1
+1 -Vincent http://xwiki.com http://xwiki.org http://massol.net
On Tue, Jan 20, 2009 at 11:56 AM, Vincent Massol <[email protected]> wrote:
Hi,
On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
Three questions: 1) Is the children information better located in a separate tab or under the Information tab?
Here's a new proposal (B) : http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children I'm +1 for B. I've first decided to put it in a separate tab for 2 reasons, to highlight the fact that a page has children and for aesthetics reasons. After some more thoughts I think that the other info in the information tab are pretty important too, children doesn't deserve a separate tab, and about the aesthetics the info tab just needed a small rewamp. Note that I display those pages list thanks to a velocity macro, which will be reusable. JV.
Jean-Vincent Drean wrote: > On Tue, Jan 20, 2009 at 11:56 AM, Vincent Massol <[email protected]> wrote: >> Hi, >> >> On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote: >> >>> Hi devs, >>> >>> There are 4 votes required, see bellow. >>> >>> 1/ UI. See the screenshot at >>> http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children >>> Note that this list comes along with a generic way of building >>> spaces/pages/attachment/comments lists (ul) in our skin files. >>> >>> Here's my +1 >> Three questions: >> 1) Is the children information better located in a separate tab or >> under the Information tab? > > Here's a new proposal (B) : > http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children > > I'm +1 for B. +1, I like it Jerome. > > I've first decided to put it in a separate tab for 2 reasons, to > highlight the fact that a page has children and for aesthetics > reasons. After some more thoughts I think that the other info in the > information tab are pretty important too, children doesn't deserve a > separate tab, and about the aesthetics the info tab just needed a > small rewamp. Note that I display those pages list thanks to a > velocity macro, which will be reusable. > > JV. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
Jean-Vincent Drean wrote: > On Tue, Jan 20, 2009 at 11:56 AM, Vincent Massol <[email protected]> wrote: >> Hi, >> >> On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote: >> >>> Hi devs, >>> >>> There are 4 votes required, see bellow. >>> >>> 1/ UI. See the screenshot at >>> http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children >>> Note that this list comes along with a generic way of building >>> spaces/pages/attachment/comments lists (ul) in our skin files. >>> >>> Here's my +1 >> Three questions: >> 1) Is the children information better located in a separate tab or >> under the Information tab? > > Here's a new proposal (B) : > http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children > > I'm +1 for B. +1 also. I would probably put the tags and creation first but that's just a preference. > > I've first decided to put it in a separate tab for 2 reasons, to > highlight the fact that a page has children and for aesthetics > reasons. After some more thoughts I think that the other info in the > information tab are pretty important too, children doesn't deserve a > separate tab, and about the aesthetics the info tab just needed a > small rewamp. Note that I display those pages list thanks to a > velocity macro, which will be reusable. > > JV. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Jan 20, 2009 at 5:20 PM, Marius Dumitru Florea <[email protected]> wrote:
Here's a new proposal (B) : http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children
I'm +1 for B.
+1 also. I would probably put the tags and creation first but that's just a preference.
That was my first try but having the "save" button in the middle of the panel looked a bit weird. JV.
On Jan 20, 2009, at 4:53 PM, Jean-Vincent Drean wrote:
On Tue, Jan 20, 2009 at 11:56 AM, Vincent Massol <[email protected]> wrote:
Hi,
On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
Three questions: 1) Is the children information better located in a separate tab or under the Information tab?
Here's a new proposal (B) : http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children
I'm +1 for B.
+1 for B. -Vincent
I've first decided to put it in a separate tab for 2 reasons, to highlight the fact that a page has children and for aesthetics reasons. After some more thoughts I think that the other info in the information tab are pretty important too, children doesn't deserve a separate tab, and about the aesthetics the info tab just needed a small rewamp. Note that I display those pages list thanks to a velocity macro, which will be reusable.
JV.
On Tue, Jan 20, 2009 at 4:53 PM, Jean-Vincent Drean <[email protected]> wrote:
On Tue, Jan 20, 2009 at 11:56 AM, Vincent Massol <[email protected]> wrote:
Hi,
On Jan 20, 2009, at 11:33 AM, Jean-Vincent Drean wrote:
Hi devs,
There are 4 votes required, see bellow.
1/ UI. See the screenshot at http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children Note that this list comes along with a generic way of building spaces/pages/attachment/comments lists (ul) in our skin files.
Here's my +1
Three questions: 1) Is the children information better located in a separate tab or under the Information tab?
Here's a new proposal (B) : http://incubator.myxwiki.org/xwiki/bin/view/Mockups/Children
I'm +1 for B.
+0
I've first decided to put it in a separate tab for 2 reasons, to highlight the fact that a page has children and for aesthetics reasons. After some more thoughts I think that the other info in the information tab are pretty important too, children doesn't deserve a separate tab, and about the aesthetics the info tab just needed a small rewamp. Note that I display those pages list thanks to a velocity macro, which will be reusable.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (8)
-
Asiri Rathnayake -
Guillaume Lerouge -
Jean-Vincent Drean -
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol