Feature Discussion or Comment pages
This page is talking about a possible feature for MoinMoin to have one ore more pages for discussion and/or comments. While in many cases it is fine or even preferable to have discussions about a page's contents on the page itself, it may sometimes be nice to have comments/discussion on seperated page(s). This is especially true for write protected pages. The question is how should we implement this feature in MoinMoin?
Contents
Please feel free to refactor this page. Be careful where to add additional content. Always keep in mind that each page needs to be kept readable! A good guide is to always start refactoring your own contributions. If everybody does that we get a much better overview. |
For the rest of this document I suggest to use the term "discussion" to indicate something like "discussion, comment or other related text or page" to keep the language used more concise. Maybe also to avoid confusion with the '## '-"comments" that are possible within the raw text of a page anyway. |
As some other tips/ideas have come up, it's probably good to keep an open mind towards a mechanism for 'discussions' that is not necessarily based on seperate pages, but might have discussions inline and tagged as such so that a 'display/parser layer' can optionally show these tagged sections depending on the user's choice (button in theme or setting in preferences or such).
If discussions are implemented as seperate pages, it should also be trivial to display an associated (sub)page with discussions as an 'included page' so that those who want it can still have the discussion visible directly on the 'main page'.
How other Wikis do it
MediaWiki uses one discussion page per page.
General Considerations
- Not just 1:1 relations - Maybe it would be good to consider the fact that some discussions might actually be relevant to more than one page (and that Wikimedia's 1:1 relation between articles and discussions doesn't really provide for this).
Take I18n into account - The simplest case being that if for example it would be decided to use some 'standard' subpage for discussions (like maybe /PageComments) it might be better to have the 'standard' name for such a page configurable as a variable somewhere. Of course, supporting multi-lingual wikis would probably require some more thought than just one variable name.
Workarounds
- Make Sub Pages
- Discussion Tree
Have pages with ending Discussion to show that people should discuss there
- Link to pages and tell people that they should discuss on the linked page.
- Use a theme that has a discussion page implemented (Monobook?)
Make a category CategoryDiscussionPage
I suppose everything (even n:n relations) could be handled by Category markers, but that system would also break real easily as soon as someone forgets to add any/all the appropriate marker(s) in a page - but it's a start -- Arp
Use PageComment2 macro to present users with an 'Add Comment' box that allows them to write their comment and then submit it to have their comment appended to the bottom of the page.
- The problem with this was(is?) that in many cases one wouldn't want comments cluttering the (bottom of) a neat documentation page. However, when implementing seperate discussion pages it might still be a good idea to have a similar add-on for those who feel it's needed.
see more below
Sub Pages
Depending on the implementation one side effect might be that now some way would be needed to distinguish between 'main pages' (that can have a discussion subpage) and such pages that can't have discussions associated (like maybe the discussion pages themselves). This could possibly be as trivial as adding a CategoryDiscussion or something to such page or meta data to the same effect and not allowing creation subpages for pages with such an identifier in it.
Pros:
- Can be implemented as a mere guideline for a quick start.
As a first step a simple link to /PageComments can be added at the top/bottom of the page contents in the template.
- As a second step it should be fairly easy to support this in code and themes to make it more accessible to novice users.
Throwing out all the discussions before redistribution means simply ignoring all "*/PageComments" pages.
Cons
It seems some people don't like subpages. One reason mentioned is that they can make renaming a hassle (to me it seems the RenamePage action could fairly easily be adapted to a 'RenameTree' for such purpose??)
n:n Relations are not straightforward. A simple first step could be to also have a standard /RelatedPages or /DiscussionIndex subpage that takes care of linking to the 'n' related discussions (and these could have links back), or to simply have the 'n' links in the /PageComments page.
- If discussion pages are created that are relevant to more than one 'main content' page there is no clearly defined location for such discussion other than maybe it being 'hosted' by one of the pages it applies to.
- I18n and support for multi-lingual wikis is not straight forward (what name(s) to use for the subpage?).
Without pinning anything down on exact names or having only one standard subpage name or various - how useful do you think this method could be?
It does the trick for what I need to do for now (works mostly as a template supported guideline), and I feel confident I'll get it integrated with the user interface quite neatly soon enough. Although my system will eventually need to be more complex with translated versions of a document, probably in subpages too, each with their own (translation)discussion page attached. Of course these would also be related to some general discussion page about the main document (hence support for n:n relations would be sort of neat). -- ArpKruithof
Discussion Tree
Another solution that might be considered is the creation of a 'Discussions' tree of subpages that more or less copies the wikis structure in a seperate tree with discussion pages for every 'real' page in the wiki that needs one. For the MoinMaster pages this might result in a tree like: {{{Discussions/HelpOnAdministration Discussions/HelpForBeginners Discussions/HelpOnInstalling Discussions/HelpOnInstalling/MinimalWiki}}}
Links to these discussion pages could be worked into the page contents (easy but ugly/unwanted) or maybe into standard themes or so (if a page with the same name exists under the /Discussion tree display a link to it)
Pros:
- Can be implemented as a mere guideline for a quick start.
As a first step a simple link to Discussions/TheNameOfThisPage can be added to the page contents in the template.
- As a second step it should be fairly easy to support this in code and themes to make it more accessible to novice users.
Filtering out the discussions simply means throwing out that one tree Discussions (all files named "Discussions/*")
The Discussions tree would also be logical place for pages that contain discussions relevant to more than one 'main content' page (1:n relations).
Cons:
n:n Relations are not straightforward. A simple first step could be to have the page Discussions/TheNameOfThisPage contain the 'n' links to (other) related discussions.
- If discussion pages are created that are relevant to more than one 'main content' page there is no clearly defined name for it other than maybe the name of one of the pages it applies to. But at least people will have a general idea where to create (or look for) such pages.
I18n and multi-lingual wikis require some extra thought (variables?) on naming the Discussions/* tree. As the names of the subpages in the tree follow the original page names the issue is probably only with the base name.
Comments:
It 'feels' a bit awkward to have the discussion page(s) 'somewhere else', but it seems to be a valid possibility. If others would feel strongly that this is the best way to go I would probably eventually rework my system to adhere to that standard. The best reason for using this I could think of now would be that it offers a more logical location for discussions that don't necessarily relate to one specific page (the n:n thingy). -- ArpKruithof
Possible Solutions
With NewPage Macro
It is not quite difficult to do it by the NewPage macro.
if parent == '@SELF': parent = f.page.page_name
is added behind the lines for @ME then you can get with [[NewPage(template,Discussion,@SELF,Discussion)]] a button labled Discussion which does create on the page where it is called a subpage /Discussion. This button could be placed where you want on the page or it could be integrated into the action menu. -- ReimarBauer DateTime(2006-08-23T20:20:21Z)
And here we have an example for an action macro for a Discussion page of a page -- ReimarBauer 2006-08-25 14:18:06
1 """
2 MoinMoin - Action for Discussion pages
3
4 This Action is used to create a subpage Discussion below a comon page
5
6 Install:
7 put it into the 'action' directory and do create a DiscussionTemplate
8
9 Note:
10 derived from the newpage macro by Vito Miliano (vito_moinnewpagewithtemplate@perilith.com) et al
11
12 Modification History:
13 2006-08-25 ReimarBauer initial version
14
15 License:
16 @license: GNU GPL, see COPYING for details.
17
18 """
19 from MoinMoin.Page import Page
20
21
22 def execute(pagename, request):
23
24 _ = request.getText
25
26 if pagename.find(_('Discussion')) != -1:
27 redir = pagename.split('/')
28 redir = '/'.join(redir[0:-1])
29 query = {'action': 'edit', 'backto': redir}
30 url = Page(request, pagename).url(request, query, escape=0, relative=False)
31 request.http_redirect(url)
32
33 newpagename = "%s/%s" % (pagename,_('Discussion'))
34
35 if request.user.may.read(newpagename) and request.user.may.write(newpagename):
36 query = {'action': 'edit', 'backto': pagename}
37
38 from MoinMoin.wikiutil import quoteWikinameURL
39 query['template'] = quoteWikinameURL('DiscussionTemplate')
40
41 url = Page(request, newpagename).url(request, query, escape=0, relative=False)
42 request.http_redirect(url)
43
44 else:
45 page = Page(request, pagename)
46 error = _('you don''t have access to the discussion page')
47 page.send_page(request, msg=error)
48 return ' '
Meta Data to find Discussion Pages
In order to create an n:1 relationship for pages:discussion, meta-tags or maybe macros could be used in the raw text of a page to indicate where the discussion for the page (or section?) takes place, and have a preprocessor and themed links point to the appropriate discussion - similar to the way this is solved for the MonthCalendar macro.
This would also alow for a series of related pages with one introduction page, where the discussion could be hosted at the intro page, and place [[DiscussAt(Intro)]] (or whatever) on each one of the related pages. Then clicking on the Discussion link from any of the related pages will take me to the discussion page related to Intro (Discussions/Intro or Intro/PageDiscussion or whatever). This may be challenging to render correctly because when directed to the discussion page, it would be good to know 1st that this is "Intro's Discussion" page and 2nd a link to return to the page of origin would be wanted.
Perhaps linking could be rendered as tabs or maybe a dropdown list or pop up box with all links to 'related pages' - being pages that link to a page with 'discusssion-tags' and/or pages that the current page links to itself, and/or maybe even a complete list of all te subpages of the current page.
Pros:
- No fixed names/locations for the discussion would have to be decided on
- Hence easy I18n
- Easy n:n realations possible
Cons:
- Definitely requires integrations into themes and supporting code
- Not easy to start implementing without above support in place
- Filtering out the (links to) discussions before redistribution not very straight forward
Comments:
Personally it seems to me this would be a very flexible system that could also provide hooks for other creative ideas for interlinking pages. I had been thinking about creating something to work a automagically created dropdown list/menu with all the subpages to a page into the theme/user interface and this would combine neatly with such an effort. -- ArpKruithof
Meta Data and Inline Discussion Sections
Having my attention drawn to the discussion on MetaDataInMoin it seems that some of the ideas presented there might very well be used to 'tag' certain sections of a page's raw text as 'discussion' (or whatever) by using either the discussed meta data tags or XML-like tags (maybe DocBook?). The parser could then either display these sections with the main content (possibly in various ways) or suppress them altogether.
I can't say anything sensible about this option until I've found time to play with it. But maybe these statements are valid anyway:
Pros:
- All-in-one: No clutter of distributed pages is needed to accomodate the discussion.
- Discussion sections can be displayed very near the 'main content' that they apply to.
- Appropriate tagging would easily allow for various 'classes' of comments/discussion or other meta-content to be displayed or not.
- I18n and multi-lingual pages are better supported as long as having 'english' tag names is not considdered to be a problem - assuming these will be invisible when the page/discussion is dispayed.
Cons:
- All-in-one: Filtering the discussions out could be more cumbersome.
All-in-one: The raw text will probably be much more cluttered with tags and discussion text, which will make editting harder for novices (I'd say it would almost require a 'section editting' mechanism to be implemented as well).
- n:n Relations between discussions and 'main content' sections/pages seem more problematic?!
Comments:
I'm certainly going to play with this because I like the idea of tagging to add more meta-structure to the contents and maybe using this for better 'printable' versions of the pages too. If it turns out that the system is very flexible I might be tempted to try and weave discussions and section editting into this to so users have a choice of displaying discussions close to their relevant 'main content' sections, or at the bottom of the page (or wherever) or not at all. But it might still have the discussion text in seperate files/pages (as includes)? -- ArpKruithof
Extending "More Actions" Menu
Mayby for now just include the patch posted on the MoinMoin users mailing list (http://permalink.gmane.org/gmane.comp.web.wiki.moin.general/4016) that adds a Comment item to the 'More Actions' menu, in order to make it easier for users to create a comment page as a corresponding subpage. I guess both, the Comment item in the menu, and the name of the subpage, could be localised via the system messages machanism, e.g. Diskussion and DiskussionsSeite in German.
However, I'ld prefer to see this solved more like it is done in MediaWiki (no, not everything in MediaWiki is bad...), i.e. a link to a "Comments" page on every page by default, maybe as a simple link like "Attachments", or as a tab like "FindPage". -- MartinBayer 2006-07-25 21:22:08
TwinPages, SisterSites, ...
While discussing on #moin-dev (2006-12-02) we maybe found a completely different and more general approach to solving the requirements above:
separation - it is on another wiki.
no need to exclude it for moin export dump, for example.
no TitleIndex pollution with comment sub pages
no i18n problem - the pagename is just the same on the original wiki and the comments wiki. Just the interwiki name is different.
if 1:1 is not enough, you can add other discussion pages and use wiki or interwiki links to refer to them.
A page on MoinMaster wiki could list some TwinPage on MoinMasterComments wiki where users can put comments.
With nice integration into theme, this should solve quite some problems and even open new possibilities, because this is a general mechanism and not limited to comments.
To show a link to the comment page, we either need some sort of "wanted sistersite" (so it display a link to that site even if the page of the same name does not exist yet) or special theme support.
Links:
FeatureRequests/SisterSites SisterServerCode TwinPages (AdoptedPages)
MacroMarket/EmbedWikiPage shows a way to embed a page from another wiki in a page
In my humble opinion, this means to prefer programmers' interests over users' interests (again). This here is likely to be the most wanted feature in MoinMoin (the second most is section editing). Please don't solve it in a way that is most easy for the developers to implement, but in a way that makes MoinMoin gaining ground in usability concerns and in competition with other wiki engines (esp. MediaWiki).
Discussion pages and the pages they are referring to need to be kept together: a discussion page will often provide information why something is or is not on the main page, or why something is wanted or not on the main page, or why something is put in that way and not in another, and so on. Both, the main page and its discussion page, need to be seen as an informational unit.
Thus, it would not be an advantage to have the discussion pages in an other wiki, and I'm not only thinking of all those who are not running a wiki farm, but need a solution that works "out of the box" in one single wiki. Also, it would not be an advantage to have the discussions not in an export dump or backup, as this might strip off usefull information from the wiki's content seen as the archivement of an editing community. As far as indices are concerned, one could think of a solution similar to that used for the template and category pages. And last but not least it would by any means break usability if links (WikiNames) on comment pages leaded to other pages or even to nowhere as they do on the corresponding main page, and vice versa. To explain the users the proper use of InterWiki links for comments would be as difficult as it is now to explain the proper use of subpages for the same scope. In view of usability, I therefore consider this a non-solution. -- MartinBayer 2006-12-04 22:21:54
I think you are mistaken. Fistly, this is not about "cloning" MediaWiki, it is about implementing something the user community wishes. Secondly, even if this meant to copy from others, it would be insensate to refuse a solution only because a competitor invented it before us. (Shame on us we did not think about it first!) Thirdly, Wikipedia is not a special use case of its own, it is just an other wiki from the type "knowledge management". And in almost any knowledge management wiki you want to show only up-to-date content, proof-read by the editor community, and not all the myths that might exist on the topic. That's why you separate the facts from the discussion.
I could not disagree more with you saying that this is against the wiki principle. Having "clean" pages does not mean not having a continuos reviewing process - far from it! They are the result of the efforts of the wiki's editor community. If you don't want to show the results in the first place, maybe a Forum is more suitable for you?
So, the only question that remains is: do we want discussion pages or don't we (it is not: do we want to clone MediaWiki)? If we want discussion pages - and this is what I think our users do -, I plea for a solution that leaves nothing to be desired for usability.
I yet again remind the existence of the Dialogue principles, Part 10 of ISO 9241 Ergonomic requirements for office work with visual display terminals, which require a dialogue system to conform to suitability for the task (the dialogue should be suitable for the user's task and skill level), self-descriptiveness (the dialogue should make it clear what the user should do next), conformity with user expectations (it should be consistent), and suitability for learning (it should support the user to learn the dialogue system). And I doubt if splitting contents from the discussion related to it is a good solution for means of usability: I already mentioned the efforts that will have to be done to train the users on the proper use of InterWiki links, and I already mentioned the overhaed work that all (volunteer) administrators will have for setting up, maintaining, and backing up two wikis instead of one. -- MartinBayer 2006-12-06 00:13:50
CommentWiki
I implemented WikiName: syntax in 1.6. Before, you had to use WikiName:PageName to get a full interwiki link, but in 1.6, if you just omit the PageName, it will take you to the same pagename in the other wiki. So having comments just means to have a CommentWiki: link in the navibar.
Can you show that new functionality on the test wiki. I believe it does teleport me to the commentwiki. If so I do like to add a config var to use something like a refactored MacroMarket/EmbedWikiPage to get the page rendered in the actual wiki so I could use acls, theme, navigation elements, macros and parsers of the current wiki. Editing the page needs to be done on the commentwiki, previewing on the currentwiki. -- ReimarBauer 2006-12-04 06:41:13
- Not yet (have to refactor some navibar code first). But if you click the comment link, it will take you to the comment wiki. There could be the same type of link to bring you back to the content wiki.
Teleporting to the other wiki is not always a problem... Not in a farm where you have CommonUserAccounts. Or? Might be a problem for true SisterSites on remote machines where you have no user account or on a farm where you don't have CommonUserAccounts.. A config var for adopting/embedding a page (see AdoptedPages) or just interwiki-linking it (see SisterSites and TwinPages) would be very nice... Use wiki rpc v3 'getPage', 'putPage' for AdoptedPages? (See my thoughts on having a new version 3 of wiki rpc at WikiRpc)
I like these ideas above very, very much. We might need this general linking concept also for AccessibleMoin. I think it shouldn't be a problem to integrate these ideas of SisterSites in Reimar's marvelous patch above for generally being able to have some supplement page to a wikipage ('Discussion', 'Image and Mediasources', 'To Dos', 'Iso Doc Remarks', 'Notes'...). The idea is: if you put u'CommentWiki:' instead of u'DiscussionTemplate' in supplementation_page_template you can change the behaviour of supplement pages in Moin. Maybe even it should be possible to provide a list of interwiki links in supplementation_page_template to have more than one sistersite only. Instead of a simple link you now get a drop-down-list-box in the theme to choose "%s on %s" % (supplementation_page_name, supplementation_page_template[0]) and so on... We need onyl to remove the ':' at the end of supplementation_page_template[0] for proper display..
Do we need this at all?
Please indicate how you feel about having an (optional) system to NOT display discussions on a 'main content' page.
I might still use the wiki but I really do need to use some workaround for this. -- ArpKruithof
I really want this. -- AlexanderChemeris
It's pretty critical. Our users won't be arsed to do that manually, which means discussion won't take place. Which means the wiki will be useless. -- kamagurka 2006-08-23 15:14:46
I really want this, too. -- DavidMontgomery
Please indicate how important it would be to you if we could agree on a method or even just a guideline (soon) so you can start implementing it in the knowledge others will use the same method and tools and enhancements can be developed together.
I'll get it done on my own eventually, but if I put effort into it I'd much rather work on something others would want to use too -- ArpKruithof
There must be standard way. -- AlexanderChemeris
Before I roll my own I'll deploy another wiki engine. -- kamagurka 2006-08-23 15:14:46
Far better to be standard, but I won't be troubled to have to do something on my own using subpages. -- DavidMontgomery
Please indicate how important it would be to you to be able to (optionally) display discussions fragments near the section of 'main content' that they discuss
5 - If a page needs to be displayed cleanly (optionally), I can live very well with discussions on a seperate page, but if it could be realized to have discussions 'blend in' or 'suppressed' by a simple click that would be brilliant too. -- ArpKruithof
- 8 - Great idea. May be use something like sidenotes?
7 - I never actually thought about this, but it would be awesome. -- kamagurka 2006-08-23 15:14:46
3 - Not important to me, although I can see some benefit. -- DavidMontgomery
Where to integrate it into the UI
Reimar, thank you for your macro. I think it could be integrated into the UI on different places:
1 |
|
calling the macro from a button in the main menu line |
2 |
|
extending the modern theme in order to have an additional tab |
3 |
|
adding the macro to the "more actions" menu |
4 |
|
putting it into the main menu line, next to "attachments", "info", and so on |
I would prefer clearly solution #4, as it is most consitent to the existing concepts of our UI. Solution #3 means to hide it from the user, and solution #1 is just ugly. Solution #2 is emulating the MediaWiki, or MonoBook theme, but less consistent than solution #4, as all other tabs are leading to (main) pages, not to (information) pages related to the current page (like "attachment", "info", and so on).
Now the tricky part:
- Which of the solutions drafted above could be done with your macro?
Without additional work it is now added to the more actions menu (3). If you like to put it in the main menu line (editbar) (4) the themes needs to be changed and a switch added to wikiconfig.py that it is on default disabled. A similiar entry to __init__.py as for infoLink needs to be added and then called in the editbarItems function. e.g.
def discussionLink(self, page): """ discussion for a page """ _ = self.request.getText return page.link_to(self.request, text=_('Discussion', formatted=False), querystr={'action': 'Discussion'}, id='discussion', rel='nofollow')
May be we should add a feature request about a configurable editbar, that would avoid a switch.A bird in the hand is worth two in the bush. I suggest to choose design #4, and to extend the themes, and the wikiconfig, both, instead of waiting for a configurable editbar to come. And I suggest to do this already for the 1.6, as this feature is something where MoinMoin could gain ground in its competition with MediaWiki. Users like discussion (or: comment) pages, and they want them in MoinMoin, too.
Extending the navibar(2) with an addtional tab means creating a page where a macro is executed if the user clicks on that page. This action macro can't be used for that and the NewPage macro would create without the page information from which page it is called from the discussion page on the wrong page. So (2) can't be solved this way. For (1) it is bad to place a button on a page because someone hitting enter executes this button. We should avoid this confusion. In principle it is a differnt definition in discussionLink necessary for that.
If it is configurable to have that entry or not I would prefer an editbar entry.
- When clicking on the link (or selecting the item from the menu or whatever), will the user be lead directly to the discussion page, if it already exists, and otherwise be promted to create such a page? (IOW, does it work just like a link to a wiki page?)
he will get the page in action=edit mode.
So, how could someone just read the discussions/ comments for a page?
How about localization? You see, I've already called it Diskussion (German), in English it should read discussion and so on.
localization should not be a problem that needs to be done the same way as for DeletePage in __init__.py search for DeletePage': _('Delete Page', formatted=False),.
Thanks, -- MartinBayer 2006-08-26 16:53:45 -- ReimarBauer 2006-08-27 10:06:50
Patch
I do think there are further changes to the theme needed and/or to the function discussion.py. E.g. we can handle it in that way that in the theme the first five lines of the discussion page is shown with a link to get the whole discussion page. And then the user can use the normal Edit action or Discussion to add some sentences. Something like more ... will than link to the Discussion page.
IMHO these "more..." things show bad taste. Plus this would privilege the fist entry on the discussion page, which not neccessarily is the most important. Plus we already have something like that, see MacroMarket/PageComment2.
If it's not wanted to see some discussion entries below the actual page the discussion action could be changed to switch only without action=edit to the discussion page and the user who want's to edit could choose the edit action. If the page does not exists a template could used to create the page. -- ReimarBauer 2006-08-27 23:55:51
I would prefer that, because in edit mode you can't read the page's contents (only in the editor). Presumely users don't want only to write comments, but also to read the comments of other users. However, if we do it that way, what difference rests between this solution and a simple link to ["./discussion"]? -- MartinBayer 2006-08-28 20:14:23
The link is enough. Then the user could decide the common way to edit or to go back to the main page. There are some more things which I have to change in this patch after some discussions with ThomasWaldmann on IRC. -- ReimarBauer 2006-08-28 20:57:52
based on 1515:b3a47164c22a a new patch for this feature -- ReimarBauer 2006-08-31 11:08:25
1 # HG changeset patch
2 # User ReimarBauer <R.Bauer@fz-juelich.de>
3 # Node ID 8b0a29e34f949b36c6ac0bf45f83d1cf81d1f3a6
4 # Parent b3a47164c22a16a37bb097a78e03342ecacf4d3b
5 Feature for a suplementation page e.g. Discussion added, default editbar is [u'Edit', u'Info', u'Subscribe', u'Quicklink', u'Attachments', u'ActionsMenu', ] This feature could be enabled by adding the supplementation_page_name to this var. On default it is named Discussion. To change it you need to set
6 supplementation_page_name = u'Comment'
7 supplementation_page_template = u'CommentTemplate'
8 edit_bar = [u'Edit', u'Info', u'Subscribe', u'Quicklink', u'Attachments', supplementation_page_name, u'ActionsMenu', ]
9
10 diff -r b3a47164c22a -r 8b0a29e34f94 MoinMoin/config/multiconfig.py
11 --- a/MoinMoin/config/multiconfig.py Tue Aug 29 17:01:55 2006 +0200
12 +++ b/MoinMoin/config/multiconfig.py Thu Aug 31 13:01:16 2006 +0200
13 @@ -235,7 +235,9 @@ class DefaultConfig:
14
15 default_markup = 'wiki'
16 docbook_html_dir = r"/usr/share/xml/docbook/stylesheet/nwalsh/html/" # correct for debian sarge
17 -
18 +
19 + edit_bar = [u'Edit', u'Info', u'Subscribe', u'Quicklink', u'Attachments', u'ActionsMenu', ]
20 +
21 editor_default = 'text' # which editor is called when nothing is specified
22 editor_ui = 'freechoice' # which editor links are shown on user interface
23 editor_force = False
24 @@ -372,6 +374,9 @@ reStructuredText Quick Reference
25 siteid = 'default'
26 stylesheets = [] # list of tuples (media, csshref) to insert after theme css, before user css
27 superuser = [] # list of unicode user names that have super powers :)
28 +
29 + supplementation_page_name = u'Discussion'
30 + supplementation_page_template = u'DiscussionTemplate'
31
32 surge_action_limits = {# allow max. <count> <action> requests per <dt> secs
33 # action: (count, dt)
34 diff -r b3a47164c22a -r 8b0a29e34f94 MoinMoin/theme/__init__.py
35 --- a/MoinMoin/theme/__init__.py Tue Aug 29 17:01:55 2006 +0200
36 +++ b/MoinMoin/theme/__init__.py Thu Aug 31 13:01:16 2006 +0200
37 @@ -1027,13 +1027,19 @@ actionsMenuInit('%(label)s');
38 This is separate method to make it easy to customize the
39 edtibar in sub classes.
40 """
41 - return [self.editorLink(page),
42 - self.infoLink(page),
43 - self.subscribeLink(page),
44 - self.quicklinkLink(page),
45 - self.attachmentsLink(page),
46 - self.actionsMenu(page),
47 - ]
48 + editbar_items = {'Edit': self.editorLink(page),
49 + 'Info': self.infoLink(page),
50 + 'Subscribe': self.subscribeLink(page),
51 + 'Quicklink': self.quicklinkLink(page),
52 + 'Attachments': self.attachmentsLink(page),
53 + self.request.cfg.supplementation_page_name: self.supplementation_page_nameLink(page),
54 + 'ActionsMenu': self.actionsMenu(page)}
55 +
56 + allowed_action = []
57 + for action in self.request.cfg.edit_bar:
58 + allowed_action.append(editbar_items[action])
59 + return allowed_action
60 +
61
62 def guiworks(self, page):
63 """ Return whether the gui editor / converter can work for that page.
64 @@ -1118,6 +1124,13 @@ var gui_editor_link_text = "%(text)s";
65 return page.link_to(self.request,
66 text=_('Info', formatted=False),
67 querystr={'action': 'info'}, id='info', rel='nofollow')
68 +
69 + def supplementation_page_nameLink(self, page):
70 + """ discussion for page """
71 + _ = self.request.getText
72 + return page.link_to(self.request,
73 + text=_(self.request.cfg.supplementation_page_name, formatted=False),
74 + querystr={'action': 'supplementation'}, id='supplementation', rel='nofollow')
75
76 def subscribeLink(self, page):
77 """ Return subscribe/unsubscribe link to valid users
78 diff -r b3a47164c22a -r 8b0a29e34f94 MoinMoin/action/supplementation.py
79 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
80 +++ b/MoinMoin/action/supplementation.py Thu Aug 31 13:01:16 2006 +0200
81 @@ -0,0 +1,42 @@
82 +"""
83 + MoinMoin - Action for supplementation pages
84 +
85 + This Action is used to create a supplementation subpage e.g. a Discussion below a comon page
86 +
87 + Install:
88 + put it into the 'action' directory and do create a supplementation Template e.g. DiscussionTemplate
89 +
90 + Note:
91 + derived from the newpage macro by Vito Miliano (vito_moinnewpagewithtemplate@perilith.com) et al
92 +
93 + Modification History:
94 + 2006-08-30 ReimarBauer initial version
95 +
96 + License:
97 + @license: GNU GPL, see COPYING for details.
98 +
99 +"""
100 +from MoinMoin.Page import Page
101 +from MoinMoin.wikiutil import quoteWikinameURL
102 +
103 +def execute(pagename, request):
104 + _ = request.getText
105 + sub_page_name = request.cfg.supplementation_page_name
106 + sub_page_template = request.cfg.supplementation_page_template
107 + newpagename = "%s/%s" % (pagename, sub_page_name)
108 +
109 + if pagename.endswith(sub_page_name): # sub_sub_page redirects to sub_page
110 + query = {}
111 + url = Page(request, pagename).url(request, query, escape=0, relative=False)
112 + request.http_redirect(url)
113 + elif request.user.may.read(newpagename) and request.user.may.write(newpagename):
114 + query = {}
115 + url = Page(request, newpagename).url(request, query, escape=0, relative=False)
116 + test = Page(request, newpagename)
117 + if test.exists(): # page is defined -> redirect
118 + request.http_redirect(url)
119 + else: # page will be created from template
120 + query = {'action': 'edit', 'backto': newpagename}
121 + query['template'] = quoteWikinameURL(sub_page_template)
122 + url = Page(request, newpagename).url(request, query, escape=0, relative=False)
123 + request.http_redirect(url)
I will do some more changes on this patch the next time (may be in two weeks).
it will be changed to be not configurable to choose the name of the supplementation page. This would be done later. At the moment it does make this patch to complicated and I believe we will later on do have a better idea to implement different names or more pages. Step by step
- I will add a new var to multiconfig.py something like ´enable_supplementation_page = False´ so it could be used to setup wikis different.
- I will add a new pragma var too. So it could be en/disable from a user for a page too
I do need a vote from you now for the first initial name of that page:
Comment |
|
Discussion |
|
-- ReimarBauer 2006-11-24 07:14:07
I would prefer the name discussion page. This is well know to most wiki users due to some well known wikiengine. I don't think we should introduce extra complexity and usability problems. Just think of the discussion about calling history info! See UsabilityObservation/HowToGetHistory . There are certain grown, inofficial standards, and we should meet them, I think. -- OliverSiemoneit 2006-12-01 18:03:27
I don't see a problem to name it discussion if the main page is always opened to edit but if not a comment is semantic the better solution. while it is not important for the solution let's see the votes. if discussion is the more known word it is easy to change. -- ReimarBauer 2006-12-01 18:44:49
New Patch for 1.6 dev
1 # HG changeset patch
2 # User ReimarBauer <R.Bauer@fz-juelich.de>
3 # Date 1165053720 -3600
4 # Node ID 7c291197f69538524c568a1c30dff4334cf59f77
5 # Parent a938bd2d6166d419dc01dafabcd7c9f0b1a73724
6 supplementation page for discussion of a page added. controlled from wikiconfig with supplementation_page = True or a new pragma var from within a page '#pragma supplementation-page on'. No supplementation page on default.
7
8 diff -r a938bd2d6166 -r 7c291197f695 MoinMoin/config/multiconfig.py
9 --- a/MoinMoin/config/multiconfig.py Fri Dec 01 19:53:43 2006 +0100
10 +++ b/MoinMoin/config/multiconfig.py Sat Dec 02 11:02:00 2006 +0100
11 @@ -383,7 +383,9 @@ reStructuredText Quick Reference
12 stylesheets = [] # list of tuples (media, csshref) to insert after theme css, before user css
13 subscribed_pages_default = [] # preload user subscribed pages with this page list
14 superuser = [] # list of unicode user names that have super powers :)
15 -
16 + supplementation_page = False
17 + supplementation_page_name = u'Discussion'
18 + supplementation_page_template = u'DiscussionTemplate'
19 surge_action_limits = {# allow max. <count> <action> requests per <dt> secs
20 # action: (count, dt)
21 'all': (30, 30),
22 diff -r a938bd2d6166 -r 7c291197f695 MoinMoin/theme/__init__.py
23 --- a/MoinMoin/theme/__init__.py Fri Dec 01 19:53:43 2006 +0100
24 +++ b/MoinMoin/theme/__init__.py Sat Dec 02 11:02:00 2006 +0100
25 @@ -1051,13 +1051,40 @@ actionsMenuInit('%(label)s');
26 This is separate method to make it easy to customize the
27 edtibar in sub classes.
28 """
29 - return [self.editorLink(page),
30 - self.infoLink(page),
31 - self.subscribeLink(page),
32 - self.quicklinkLink(page),
33 - self.attachmentsLink(page),
34 - self.actionsMenu(page),
35 - ]
36 +
37 + editbar_items = {'Edit': self.editorLink(page),
38 + self.request.cfg.supplementation_page_name:
39 + self.supplementation_page_nameLink(page),
40 + 'Info': self.infoLink(page),
41 + 'Subscribe': self.subscribeLink(page),
42 + 'Quicklink': self.quicklinkLink(page),
43 + 'Attachments': self.attachmentsLink(page),
44 + 'ActionsMenu': self.actionsMenu(page)
45 + }
46 + edit_bar = [u'Edit', u'Info', u'Subscribe', u'Quicklink', u'Attachments', u'ActionsMenu', ]
47 + if self.request.cfg.supplementation_page == True:
48 + if self.request.getPragma('supplementation-page', 1) == 'off':
49 + edit_bar = edit_bar
50 + else:
51 + edit_bar.insert(1, self.request.cfg.supplementation_page_name)
52 + else:
53 + if self.request.getPragma('supplementation-page', 1) == 'on':
54 + edit_bar.insert(1, self.request.cfg.supplementation_page_name)
55 + else:
56 + edit_bar = edit_bar
57 +
58 +
59 + allowed_action = []
60 + for action in edit_bar:
61 + allowed_action.append(editbar_items[action])
62 + return allowed_action
63 +
64 + def supplementation_page_nameLink(self, page):
65 + """ discussion for page """
66 + _ = self.request.getText
67 + return page.link_to(self.request,
68 + text=_(self.request.cfg.supplementation_page_name, formatted=False),
69 + querystr={'action': 'supplementation'}, id='supplementation', rel='nofollow')
70
71 def guiworks(self, page):
72 """ Return whether the gui editor / converter can work for that page.
73 diff -r a938bd2d6166 -r 7c291197f695 MoinMoin/action/supplementation.py
74 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
75 +++ b/MoinMoin/action/supplementation.py Sat Dec 02 11:02:00 2006 +0100
76 @@ -0,0 +1,42 @@
77 +"""
78 + MoinMoin - Action for supplementation pages
79 +
80 + This Action is used to create a supplementation subpage e.g. a Discussion below a comon page
81 +
82 + Install:
83 + put it into the 'action' directory and do create a supplementation Template e.g. DiscussionTemplate
84 +
85 + Note:
86 + derived from the newpage macro by Vito Miliano (vito_moinnewpagewithtemplate@perilith.com) et al
87 +
88 + Modification History:
89 + 2006-08-30 ReimarBauer initial version
90 +
91 + License:
92 + @license: GNU GPL, see COPYING for details.
93 +
94 +"""
95 +from MoinMoin.Page import Page
96 +from MoinMoin.wikiutil import quoteWikinameURL
97 +
98 +def execute(pagename, request):
99 + _ = request.getText
100 + sub_page_name = request.cfg.supplementation_page_name
101 + sub_page_template = request.cfg.supplementation_page_template
102 + newpagename = "%s/%s" % (pagename, sub_page_name)
103 +
104 + if pagename.endswith(sub_page_name): # sub_sub_page redirects to sub_page
105 + query = {}
106 + url = Page(request, pagename).url(request, query, escape=0, relative=False)
107 + request.http_redirect(url)
108 + elif request.user.may.read(newpagename) and request.user.may.write(newpagename):
109 + query = {}
110 + url = Page(request, newpagename).url(request, query, escape=0, relative=False)
111 + test = Page(request, newpagename)
112 + if test.exists(): # page is defined -> redirect
113 + request.http_redirect(url)
114 + else: # page will be created from template
115 + query = {'action': 'edit', 'backto': newpagename}
116 + query['template'] = quoteWikinameURL(sub_page_template)
117 + url = Page(request, newpagename).url(request, query, escape=0, relative=False)
118 + request.http_redirect(url)
Documentation
From within wikiconfig it could be controlled. The default configuration given from multiconfig is:
supplementation_page |
False |
supplementation_page_name |
u'Discussion' |
supplementation_page_template |
u'DiscussionTemplate' |
From within a page a user could control it if he sets a pragma on that page.
#pragma supplementation-page off |
disables the link to the supplementation_page_name for this page |
#pragma supplementation-page on |
enables the link to the supplementation_page_name for this page |
If it is enabled it looks like:
-- ReimarBauer 2006-12-02 10:32:09
Old Discussion
Although I've worked most of this into the above text I'll leave these original discussions to still react to or as a reference for now...
In order to create an n:1 relationship for pages:discussion, we could add a macro/meta-tag/preprocessor/?? to a page to indicate where the discussion for the page takes place, and have the themed links point to the appropriate discussion - similar to the way this is solved for the MonthCalendar macro. Thus, my wiki may have a series of related pages with one introduction page - I would host the discussion at the intro page, and place [[DiscussAt(Intro)]] (or whatever) on each one of the related pages. Then clicking on the Discussion link from any of the related pages will take me to the discussion page related to Intro (Discussions/Intro or Intro/PageDiscussion or whatever). This may be challenging to render correctly because when I land on the discussion page, I would want to know 1st that I'm on "Intro's Discussion" page and 2nd that I can easily return to the page I came from - perhaps these could be rendered as tabs or similar.
- Another similar solution would be to automatically host discussions on the parent page (I actually like subpages ;-)).
Hi Ian, thanks for the contribution! I think this variant was definitely missing from the above list so I reworked it a bit and gave it a place there and added a vote/comment header for it. Please do feel free to:
Rework that (or any other) text in the proposals section.
Also leave your vote/comments on any of the items prepared for that (or add your own). --Arp
- pages can be marked as discussion pages and you can tell a wiki page what discussion page should be used. Why that? Because in Wikipedia there is the problem that a 1:1 solution for discussion means that related discussion are discussed on seperated pages. but discussion really is tending to be for more than one page.
I very much like the idea of having a n:n relation between possible 'main' and 'discussion' pages - excellent suggestion! At the same time I'm a bit worried that it would make the system less transparent/straigtforward to use (to find all related discussionnpages with a page and vice versa) so it would probably really need software support within the moin code as oposed to being just a guideline or so - but surely something to keep in mind while thinking about solutions -- ArpKruithof
General Discussion
MartinBayer reverted my two hours work where I tried to condense the discussion that has gotten more and more messy. See also his comments on my homepage: ThiloPfennig. I do not agree that this is a discussion page. I think this is a FeatureRequest that needs to go from ThreadMode to DiscussionMode. This is not a page for 1-2 people who actually still know where what belongs. We need overview and not the same arguments in every place. I especially diagree very much disagree to tell people to add their comments where they like without considering the effects. I have moved Martins comments to another place, although I found it to me more general. I would very much appreciate if we could work on some points of criticim and not go into an EditWar. So please talk before you act and better make this version better before you destroy hard work (I have reverted my version one time) -- ThiloPfennig 2006-12-06 15:14:16
Everybody is invited to participate on the page FeatureRequestsDiscussion
The logic/structure of this page does confuse me now a bit. If you like to refactor it you may think on splitting it in more than one FeatureRequest. From my point of view the summarizing of ThomasWaldmann over sister pages and my derived patch with the discussion of OliverSiemoneit does solve a lot of the issues here. As always MoinMoin policy is not trying to make a "perfect release" there will be something opened for further discussions and may be something new too. We have used with the users homepage on MoinMaster and MoinMoin already something like a sister page without generalizing it. I do prefer the possibility to choose between sister pages and embedded pages. I do have needs for boths in our wikis. If you like to move my comment to a better place feel free to do it. -- ReimarBauer 2006-12-06 19:56:27
I have put all solutions and workarounds in some sections. You misunderstood my edits. I agree the to points you have made. And I also think that all solutions that really are other feature requests should move to other pages. my refactoring was not ment to unsolve a solved issue but rather to make this page more readable. I also think that many points are now solved. I think if we really have THE final solution somebody could write a summary of what will be definitely implemented. -- ThiloPfennig 2006-12-06 22:51:03
some new ideas to get this i18 trouble off
1 # -*- coding: iso-8859-1 -*-
2 """
3 MoinMoin - Action for supplementation pages
4
5 This Action is used to create a supplementation subpage e.g. a Discussion page below a comon page
6
7 Note:
8 derived from the newpage macro by Vito Miliano (vito_moinnewpagewithtemplate@perilith.com) et al
9
10 @copyright: 2006-2007 ReimarBauer
11 @license: GNU GPL, see COPYING for details.
12 """
13 import StringIO
14 from MoinMoin.Page import Page
15 from MoinMoin import wikiutil
16 from MoinMoin.wikiutil import quoteWikinameURL
17 from MoinMoin.action import edit
18
19 def execute(pagename, request):
20 _ = request.getText
21 sub_page_name = request.cfg.supplementation_page_name
22 sub_page_template = request.cfg.supplementation_page_template
23 newpagename = "%s/%s" % (pagename, sub_page_name)
24
25 if pagename.endswith(sub_page_name): # sub_sub_page redirects to sub_page
26 query = {}
27 url = Page(request, pagename).url(request, query, escape=0, relative=False)
28 request.http_redirect(url)
29 elif request.user.may.read(newpagename) and request.user.may.write(newpagename):
30 query = {}
31 url = Page(request, newpagename).url(request, query, escape=0, relative=False)
32 page = Page(request, newpagename)
33 if page.exists(): # page is defined -> redirect
34 pagecontent = page.get_raw_body()
35 from MoinMoin.parser.text_moin_wiki import Parser as WikiParser
36 request.emit_http_headers()
37 request.setContentLanguage(request.lang)
38 request.theme.send_title(_("Discussion of %s") % pagename, pagename=newpagename)
39 # Start content - IMPORTANT - without content div, there is no direction support!
40 request.write(request.formatter.startContent("content"))
41 parser = WikiParser(pagecontent, request)
42 request.formatter.setPage(page)
43 parser.format(request.formatter)
44 request.theme.send_footer(newpagename)
45 request.theme.send_closing_html()
46 else: # page will be created from template
47 edit.execute(newpagename, request)
1 # -*- coding: iso-8859-1 -*-
2 """
3 MoinMoin - Action for editsupplementation pages
4
5 This Action is used to edit a supplementation subpage e.g. a Discussion page below a comon page
6
7 @copyright: 2006-2007 ReimarBauer
8 @license: GNU GPL, see COPYING for details.
9 """
10 from MoinMoin.action import edit
11
12 def execute(pagename, request):
13 _ = request.getText
14 sub_page_name = request.cfg.supplementation_page_name
15 sub_page_template = request.cfg.supplementation_page_template
16 newpagename = "%s/%s" % (pagename, sub_page_name)
17
18 edit.execute(newpagename, request)
1 --- __init__.py 2007-01-09 21:56:09.000000000 +0100
2 +++ /usr/lib/python2.4/site-packages/MoinMoin/theme/__init__.py 2007-01-10 21:04:04.000000000 +0100
3 @@ -1053,8 +1053,13 @@
4 This is separate method to make it easy to customize the
5 edtibar in sub classes.
6 """
7 + sub_page_name = self.request.cfg.supplementation_page_name
8 + editorlink = self.editorLink(page)
9 + if page.page_name.endswith(sub_page_name):
10 + editorlink = editorlink.replace('action=edit','action=editsupplementation')
11 + editorlink = editorlink.replace(sub_page_name,'')
12
13 - editbar_items = {'Edit': self.editorLink(page),
14 + editbar_items = {'Edit': editorlink,
15 self.request.cfg.supplementation_page_name:
16 self.supplementation_page_nameLink(page),
17 'Info': self.infoLink(page),
ToDo: patch of edit, patch of RenamePage action, patch of PageList
- edit needs to change the url to Page?action=supplementation
RenamePage needs to rename the supplementation sub page too
PageList the supplementation needs to be hidded from that
- Template usage needs to be added
it works now the following way.
If you select discussion you get if the supplementation page exists this loaded and you get the url MyExample?action=supplementation&editor=text shown. The edit url is changed to MyExample/?action=editsupplementation&editor=text and does call edit to change the page. If the page doesn't exist it is created. So we don't see in the url the complete pagename. -- ReimarBauer 2007-01-10 21:01:35
The i18n problems are still open any ideas are welcome. -- ReimarBauer 2007-01-13 20:28:03
CategoryFeatureImplemented (in 1.6)