From nirs at freeshell.org Thu Jan 2 06:16:38 2003 From: nirs at freeshell.org (Nir Soffer) Date: Thu Jan 2 06:16:38 2003 Subject: [Moin-devel] Hebrew Translation Message-ID: <857DE719-1E5C-11D7-B263-000502B6C537@freeshell.org> Hello everybody! I am trying to translate Moin Moin to Hebrew, and I need some help. My Hebrew efforts so far, and some questions: http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi?HebrewTranslation The Hebrew Moin Moin translated so far is here: http://nirs.freeshell.org/moin.cgi This will open an Hebrew page - not the typical FrontPage I don't understand how the localized system is working in Moin Moin. I suggest a Cocoa like localization system here: http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi?CocoaLikeLocalizationSystem You can find Info about me at: http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi?CocoaLikeLocalizationSystem Thanks, Nir From noreply at sourceforge.net Thu Jan 2 11:21:16 2003 From: noreply at sourceforge.net (noreply at sourceforge.net) Date: Thu Jan 2 11:21:16 2003 Subject: [Moin-devel] [ moin-Feature Requests-585211 ] parser plugins Message-ID: Feature Requests item #585211, was opened at 2002-07-23 03:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=585211&group_id=8482 Category: None Group: None Status: Open Priority: 5 Submitted By: Brian P Templeton (plovre) Assigned to: Nobody/Anonymous (nobody) Summary: parser plugins Initial Comment: Similar to action and macro plugins. This can be done easily by adding plugin-loading code to Page.py (cf. wikiaction.py). ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2003-01-02 20:11 Message: Logged In: YES user_id=100649 #format python (set a parser for a whole page) {{{!#gnuplot ... }}} (set a processor for some code) If I did not miss anything in the feature request, this should be deleted, because the features are there meanwhile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=585211&group_id=8482 From cybernetemail121302 at yahoo.com Sun Jan 5 08:47:02 2003 From: cybernetemail121302 at yahoo.com (Aassa) Date: Sun Jan 5 08:47:02 2003 Subject: [Moin-devel] >>15.2 MILLION EMAIL ADDRESSES...PLUS $2,000 IN FREE EMAIL MARKETING SOFTWARE! Message-ID: WOULD YOU LIKE TO HAVE YOUR MESSAGE SEEN BY OVER 15.1 MILLION TARGETED PROSPECTS DAILY? Below contains all the information you will ever need to market your product or service on the Internet. If you have a product, service, or message that you would like to get out to Thousands, Hundreds of Thousands, or even Millions of people, you have several options. Traditional methods include print advertising, direct mail, radio, and television advertising. They are all effective, but they all have two catches: They're EXPENSIVE and TIME CONSUMING. Not only that, you only get ONE SHOT at making your message heard by the right people. Also, Internet Search Engine Submissions, Classified Ads, Newsgroup Postings simply DO NOT WORK effectively. Now this has all changed! Thanks to the top programmers in the world and their NEW EMAIL TECHNOLOGY, You can send millions of email messages daily for FREE...Without getting terminated from your current Internet connection! It's very simple to do and you can be increasing your sales within minutes of installing this new extraordinary software! Besides...It's the only real way to advertise on the Internet that works...Period! >>>WE WILL SUPPLY YOU WITH OVER 15.1 MILLION OPT-IN EMAIL ADDRESSES TO GET YOU STARTED RIGHT AWAY! >>>PLUS FREE EMAIL ADDRESS DOWNLOADS FOR LIFE! >>>ALSO, YOU WILL RECEIVE $2,000 WORTH OF EMAIL MARKETING SOFTWARE FREE! Including...... BROADCAST EMAIL SENDING SOFTWARE...(send millions of email advertisements daily with a few clicks of your mouse, without getting your ISP trerminated. We used the same software to send you this email) EMAIL EXTRACTION SOFTWARE...(retrieve new targeted email addresses daily. Hundreds of thousands of them) LIST MANAGEMENT SOFTWARE...(keep your lists clean, opt-in and manage all your remove requests, leads, sales etc...) and much...much more! Hurry...This extraordinary offer ends at midnight tonight! To find out more information, Do not respond by email. Instead, click on the link below or copy and paste the exact web site address below into your web browser. http://www.vvorldvvideventures.com/504305/addresses.htm ______________________________________________________ Want to be removed from our email list? You were sent this email because you used our Opt-in service. We hope you enjoy reading our messages. However, if you'd rather not receive future e-mails from us, Go to our remove page at http://www.vvorldvvideventures.com/504305/remove.htm _______________________________________________________ From festifn at rupert.informatik.uni-stuttgart.de Wed Jan 8 04:17:07 2003 From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi) Date: Wed Jan 8 04:17:07 2003 Subject: [Moin-devel] Enhanced SysInfo macro Message-ID: Hi! I slightly modified the Sysinfo macro. It now also shows the size of all pages in bytes. The work is done by a small function in wikiutil.py. I think counting bytes gives a much better idea over the size of a wiki than the count of possibly empty pages. cu Florian Festi -------------- next part -------------- diff -u --from-file=../../moin/MoinMoin/ ../../moin/MoinMoin/wikimacro.py ./wikimacro.py --- ../../moin/MoinMoin/wikimacro.py Thu Aug 1 20:07:52 2002 +++ ./wikimacro.py Wed Jan 8 14:51:09 2003 @@ -247,7 +247,7 @@ row(_('MoinMoin Version'), _('Release %s [Revision %s]') % (version.release, version.revision)) if ftversion: row(_('4Suite Version'), ftversion) - row(_('Number of pages'), len(wikiutil.getPageList(config.text_dir))) + row(_('Number of pages'), _('%i (%i bytes)') % (len(wikiutil.getPageList(config.text_dir)), wikiutil.getTextSize(config.text_dir))) row(_('Number of backup versions'), len(wikiutil.getBackupList(config.backup_dir, None))) edlog = editlog.EditLog(self.request) row(_('Entries in edit log'), _("%(logcount)s (%(logsize)s bytes)") % diff -u --from-file=../../moin/MoinMoin/ ../../moin/MoinMoin/wikiutil.py ./wikiutil.py --- ../../moin/MoinMoin/wikiutil.py Thu Nov 28 20:50:21 2002 +++ ./wikiutil.py Wed Jan 8 14:49:45 2003 @@ -210,6 +210,19 @@ result.append(file) return map(unquoteFilename, result) +def getTextSize(text_dir): + """ Returns bytes used by all pages, except for "CVS" directories, + hidden files (leading '.') and temp files (leading '#') + """ + pages = os.listdir(text_dir) + result = 0 + for file in pages: + if file[0] in ['.', '#'] or file in ['CVS']: continue + try: + result = result + os.path.getsize(os.path.join(text_dir, file)) + except os.error: + pass + return result def getPageDict(text_dir): """ Return a dictionary of page objects for all pages, From noreply at sourceforge.net Wed Jan 8 11:29:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 8 11:29:01 2003 Subject: [Moin-devel] [ moin-Bugs-664583 ] typo on default page Message-ID: Bugs item #664583, was opened at 2003-01-08 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664583&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chuck Adams (skeptopotamus) Assigned to: Nobody/Anonymous (nobody) Summary: typo on default page Initial Comment: The home page in the default install reads: To create you own templates, add a page with a name ending in Template. It should be "To create your own templates" ... Normally I wouldn't point out typos in pages, being such little things as they are, but this is on the home page of the default install, and it's hardwired into the source in Page.py at that. I want to pitch moin to the suits to use for knowledge engineering, but I don't want them to see a defect on the front page... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664583&group_id=8482 From noreply at sourceforge.net Wed Jan 8 11:36:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 8 11:36:04 2003 Subject: [Moin-devel] [ moin-Bugs-664589 ] forced binary stdout/stderr confuses some servers Message-ID: Bugs item #664589, was opened at 2003-01-08 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664589&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chuck Adams (skeptopotamus) Assigned to: Nobody/Anonymous (nobody) Summary: forced binary stdout/stderr confuses some servers Initial Comment: I'm serving moin with tinyweb, and was being driven insane by seeing no output produced by the script, even when I wrapped everyting in try/catch and even forced a text/plain header as the very first line of the cgi driver. I looked into cgimain.py and saw these suspicious looking lines: if sys.platform == "win32" and not properties.get ('standalone', 0): import msvcrt msvcrt.setmode(sys.stdin.fileno(), os.O_BINARY) msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY) Commenting them out fixed the problem. This sort of os- level fiddling really needs to be a configuration item, and broken out into a module like "platformhacks.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664589&group_id=8482 From kkinder at rackspace.com Wed Jan 8 12:23:40 2003 From: kkinder at rackspace.com (Ken Kinder) Date: Wed Jan 8 12:23:40 2003 Subject: [Moin-devel] Xml Pages Message-ID: <1042057207.2704.77.camel@kkinder> Is it just me or is the xslt processor for 4suite built against an extremely old version of 4suite? Has anyone been using this or is it maintained? -Ken -- Ken Kinder Requirements Manager; Core Team -- Rackspace Managed Hosting(tm) 210-892-4025 x1095 From nirs at freeshell.org Mon Jan 13 14:22:03 2003 From: nirs at freeshell.org (Nir Soffer) Date: Mon Jan 13 14:22:03 2003 Subject: [Moin-devel] found error, now what? Message-ID: <4C2473D5-2745-11D7-AFAD-000502B6C537@freeshell.org> I did cvs update and installed the latest version. I got a compile error with MoinMoin/until/wikiext.py. So I opened the file and found too strange lines, probably someone forget to take them out: on line 57: !!!!!!!!!!!!!!!!!!!!! and on line 69: ------------------------- so I commented out these and the install was fine. Now how can I send the fix back? I never did this before - help me once and I will do it myself next time :) and write a help page on that on the wiki P.S. Come to the see the first Hebrew Moin Moin wiki at: http://mac.plonter.co.il/plonwiki (hebrew) From jh at web.de Wed Jan 15 12:07:13 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 15 12:07:13 2003 Subject: [Moin-devel] found error, now what? In-Reply-To: <4C2473D5-2745-11D7-AFAD-000502B6C537@freeshell.org> Message-ID: On Tue, 14 Jan 2003 00:21:01 +0200, Nir Soffer wrote: >Now how can I send the fix back? I will just finally finish that code. Please report errors in CVS installations here first, not on sf.net. Ciao, J?rgen From obh at telenor.net Wed Jan 15 17:33:12 2003 From: obh at telenor.net (Ole Bjørn Hessen) Date: Wed Jan 15 17:33:12 2003 Subject: [Moin-devel] webapi/cgiMoin.py and isSSL Message-ID: <200301160132.CAA01498@rocs2.nm2.telenor.net> Hi, our apache server running on a Solaris machine, doesn't set SSL_PROTOCOL/SSL_PROTOCOL_VERSION. Only the enviroment variable "HTTPS" is set to "on". So I had to pach the isSSL function like the following code. httpd -v -V Server version: Apache/1.3.26 (Unix) Server built: Jun 28 2002 18:54:00 def isSSL(): """ Return true if we are on a SSL (https) connection. """ return os.environ.get('SSL_PROTOCOL', '') != '' or \ os.environ.get('SSL_PROTOCOL_VERSION', '') != '' or \ os.environ.get('HTTPS', '') != '' Ole Bj?rn Hessen From jh at web.de Thu Jan 16 11:08:02 2003 From: jh at web.de (Juergen Hermann) Date: Thu Jan 16 11:08:02 2003 Subject: [Moin-devel] webapi/cgiMoin.py and isSSL In-Reply-To: <200301160132.CAA01498@rocs2.nm2.telenor.net> Message-ID: On Thu, 16 Jan 2003 02:32:48 +0100 (MET), Ole Bj?rn Hessen wrote: >Hi, our apache server running on a Solaris machine, doesn't set >SSL_PROTOCOL/SSL_PROTOCOL_VERSION. >Only the enviroment variable "HTTPS" is set to "on". >So I had to pach the isSSL function like the following code. A version of the patched file would help, since such code is already in CVS. Ciao, J?rgen From ntrout at rockstarvancouver.com Tue Jan 28 09:43:09 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Tue Jan 28 09:43:09 2003 Subject: [Moin-devel] Page Permissions Message-ID: <41647A6597ADD611803C005004D19FD23B33AE@MAILMAN> Hi, I'm trying to implement an exclusive page editing lock in MoinMoin. I tried doing this by adding "Locks" class to PageEditor. I maintain a file which lists pages that people started editing and don't allow people to edit files that are currently edited. There is also a timer (of one hour) which allows for the case where a page is opened for editing but noone saves it back for whatever reason (eg. close the browser, a crash, follow a link off site etc). It then occurred to me that I could to the edit locking through the Security Permissions in the site config. I could override the edit check and lock a page when this first called, then unlock it when it is saved. Unfortunately I cant tell the difference between an edit query on beginning editing a page, a preview and a save. I'd really not alter the Moin source extensively as I'd like to swap in new versions easily. I could use Permissions to do this is there was some sort of called to Permissions or callback for "edit page", "save page". If not done by overriding virtual methods here, how else might this be done? Has anyone else implemented this functionality? It could be extended to set permissions on individual pages eg. to set unreadable to certain people, or a certain times etc. Moin is an excellent wiki but people are complaining to me about losing their changes and don't want to do merging! I'd like to do this properly and perhaps I could feed it back to be integrated? Any feedback gratefully received, Nick From festifn at rupert.informatik.uni-stuttgart.de Wed Jan 29 03:49:02 2003 From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi) Date: Wed Jan 29 03:49:02 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23B33AE@MAILMAN> Message-ID: > Hi, I'm trying to implement an exclusive page editing lock in MoinMoin. I > tried doing this by adding "Locks" class to PageEditor. I maintain a file > which lists pages that people started editing and don't allow people to edit > files that are currently edited. There is also a timer (of one hour) which > allows for the case where a page is opened for editing but noone saves it > back for whatever reason (eg. close the browser, a crash, follow a link off > site etc). I is perhaps much easier to use lock files, perhaps data/pages/QuotedPageName/edit.lck . File operations are atomic and file have a modified time, which could be useful. > It then occurred to me that I could to the edit locking through the Security > Permissions in the site config. I could override the edit check and lock a > page when this first called, then unlock it when it is saved. Unfortunately > I cant tell the difference between an edit query on beginning editing a > page, a preview and a save. You will have to modify PageEditor.send_editor and PageEditor.save_page. All information metioned above is available in this method. I would not use file permissions to block the page, but read the lock file in PageEditor.send_editor. You may want to use request.form['datestamp'].value which is the timestamp of the file that was send for editing. > I'd really not alter the Moin source extensively as I'd like to swap in new > versions easily. I could use Permissions to do this is there was some sort > of called to Permissions or callback for "edit page", "save page". If not > done by overriding virtual methods here, how else might this be done? > > Has anyone else implemented this functionality? It could be extended to set > permissions on individual pages eg. to set unreadable to certain people, or > a certain times etc. Moin is an excellent wiki but people are complaining to > me about losing their changes and don't want to do merging! I'd like to do > this properly and perhaps I could feed it back to be integrated? I doubt this is a feature many people will want to have in MoinMoin. (I heard that some search engines like to try the edit URLs) Perhaps it is more worth to put some work in collision resolving. cu Florian Festi From tbird20d at yahoo.com Wed Jan 29 08:33:05 2003 From: tbird20d at yahoo.com (Tim Bird) Date: Wed Jan 29 08:33:05 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: Message-ID: <20030129163244.60042.qmail@web20808.mail.yahoo.com> Nick, Just thought I'd add my 2 cents to the discussion. I agree with Florian that this is better handled with separate lock files than with physical file locks. I, for one, would be interested in this feature. But maybe it would be better to do something that was advisory rather than mandatory. This can be important in the cases you mentioned where a an edit was abandoned. Having to wait for a lock to expire or call on an administrator to break a lock would be a huge hassle. I'd appreciate something as simple as a notice - before the page edit came up (or at the top of the edit page) - that it appears that someone is already editing the page (and maybe who it was). Then the user could decide if they wanted to continue (make their edits and save) or not. This should solve most of the collision problems, if the notice is prominent enough and people pay attention to it. What you're really trying to fix is the very annoying situation where you've spent a long time editing a page, only to find out someone has submitted data ahead of you, and now you have to reconcile the two submissions. In the case where someone started their edit before you, you can be advised to wait until their done to start your long edit. In the case where someone starts their edit after you, they can be advised that you are working on it, and back off to let you finish. If people consistently abandon edits midstream, that's a training problem, and if people ignore the warning about another edit in progress, that's a social problem. The final problem, of someone being an "edit hog", is also a social problem, but is present whether there's a locking system, notice system, or even the current edit-at-will system. Most wikis should have such a problem!! :^) Just some thoughts... Tim Bird ===== Tim Bird Embedded Linux Consultant tim at bird.org Tim Bird Consulting 801-221-5852 http://www.bird.org/ From tw at waldmann-edv.de Wed Jan 29 09:34:03 2003 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Wed Jan 29 09:34:03 2003 Subject: [Moin-devel] Page Permissions References: <20030129163244.60042.qmail@web20808.mail.yahoo.com> Message-ID: <3E380FD9.8030902@waldmann-edv.de> Hi Tim, > I, for one, would be interested in this feature. But maybe it would > be better to do something that was advisory rather than mandatory. Yes. That's more fault-tolerant. Just say "this page is being edited since by " in big red letters and let it to the user ... greetings, Thomas From jh at web.de Wed Jan 29 11:44:01 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 29 11:44:01 2003 Subject: [Moin-devel] Upgrading info Message-ID: Please help to bring v1.1 into life and add anything you can think of (the CHANGES file is a good start) to http://twistedmatrix.com/users/jh.twistd/master/moin.cgi/HelpOnUpdating#update-1-1 Ciao, J?rgen From ntrout at rockstarvancouver.com Wed Jan 29 12:24:07 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Wed Jan 29 12:24:07 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD3EF@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FE4@MAILMAN> > From: moin-devel-admin at lists.sourceforge.net > [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of > Florian Festi > Sent: January 29, 2003 3:47 AM > I is perhaps much easier to use lock files, perhaps > data/pages/QuotedPageName/edit.lck . File operations are atomic and > file have a modified time, which could be useful. One file for each page would probably be easier. Where would be a good place to put these files? Should I create a new directory called, say, data/editlocks? > > It then occurred to me that I could to the edit locking > through the Security > > Permissions in the site config. I could override the edit > check and lock a > > page when this first called, then unlock it when it is > saved. Unfortunately > > I cant tell the difference between an edit query on > beginning editing a > > page, a preview and a save. > > You will have to modify PageEditor.send_editor and > PageEditor.save_page. > All information metioned above is available in this method. I > would not use > file permissions to block the page, but read the lock file in > PageEditor.send_editor. You may want to use > request.form['datestamp'].value which is the timestamp of the > file that > was send for editing. This is what I have done so far. I wanted to know if there was a way of doing this without altering the Moin code base. Having a personalised site permissions would allow you to lock certain pages to certain users without altering the Moin code. However you can only stop editing, not manage editing, with the current set up. I will look into simplifying my implementation to using individual lock files. Thanks for the request.form['datestamp'].value information. > > Has anyone else implemented this functionality? It could be > extended to set > > permissions on individual pages eg. to set unreadable to > certain people, or > > a certain times etc. Moin is an excellent wiki but people > are complaining to > > me about losing their changes and don't want to do merging! > I'd like to do > > this properly and perhaps I could feed it back to be integrated? > > I doubt this is a feature many people will want to have in > MoinMoin. It would be nice if it were optional. I'm sure not everyone uses all of the features of MoinMoin. > Perhaps it is more worth to put some work in collision resolving. How would you suggest doing this? Nick From festifn at rupert.informatik.uni-stuttgart.de Wed Jan 29 13:05:04 2003 From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi) Date: Wed Jan 29 13:05:04 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FE4@MAILMAN> Message-ID: > > I is perhaps much easier to use lock files, perhaps > > data/pages/QuotedPageName/edit.lck . File operations are atomic and > > file have a modified time, which could be useful. > > One file for each page would probably be easier. Where would be a good > place to put these files? Should I create a new directory called, say, > data/editlocks? I would suggest data/pages/QuotedPageName/edit.lck (You have to create QuotedPageName if it doen't exist). If I understood the filesystem layout right this would be the right place, but perhaps could Juergen Hermann tell you the correct place insted. > This is what I have done so far. I wanted to know if there was a way of > doing this without altering the Moin code base. Having a personalised > site permissions would allow you to lock certain pages to certain users > without altering the Moin code. However you can only stop editing, not > manage editing, with the current set up. I will look into simplifying my > implementation to using individual lock files. I don't think this can be done withou touching MoinMoin code. > > Perhaps it is more worth to put some work in collision resolving. > > How would you suggest doing this? Do something like CVS does. Apply the right diff and on collision insert both version of the problematic lines into the file and tell the user to fix the problem. cu Florian Festi From ntrout at rockstarvancouver.com Wed Jan 29 13:09:04 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Wed Jan 29 13:09:04 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD3F0@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FE5@MAILMAN> > From: moin-devel-admin at lists.sourceforge.net > [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of Tim Bird > Sent: January 29, 2003 8:33 AM > Just thought I'd add my 2 cents to the discussion. thanks. > I agree with Florian that this is better handled with separate > lock files than with physical file locks. I'm not using physical locks (I assume you mean readonly locking here?), I don't know where that came from. Currently I have a file which contains all the pages that are locked, by whom and what time editing started. There is potential for this file to be requested chnaged by multiple requests on a busy system which might cause some problems and annoyance so I may change this to a single file per page. > I, for one, would be interested in this feature. But maybe it would > be better to do something that was advisory rather than mandatory. > This can be important in the cases you mentioned where a an > edit was abandoned. Having to wait for a lock to expire or > call on an administrator to break a lock would be a huge hassle. I was thinking of 3 levels of locking, chosen in your moin_config.py: none (off), a warning that the page is being edited, and a message that the page is locked as it is being edited. The time out could also be set by the config. > I'd appreciate something as simple as a notice - before the page > edit came up (or at the top of the edit page) - that it appears > that someone is already editing the page (and maybe who it was). > Then the user could decide if they wanted to continue (make > their edits and save) or not. Sounds good to me. > This should solve most of the collision problems, if the notice is > prominent enough and people pay attention to it. What you're > really trying to fix is the very annoying situation where you've > spent a long time editing a page, only to find out someone has > submitted data ahead of you, and now you have to reconcile the > two submissions. In the case where someone started their edit > before you, you can be advised to wait until their done to start > your long edit. In the case where someone starts their edit after > you, they can be advised that you are working on it, and back off > to let you finish. Yes, its incredibly annoying when this happens. New wiki users get really upset when they lose their changes. Its hard enough trying to get them to use it and add information, without them being discouraged by losing their changes! > If people consistently abandon edits midstream, that's a > training problem, and if people ignore the warning about another > edit in progress, that's a social problem. The final problem, > of someone being an "edit hog", is also a social problem, but > is present whether there's a locking system, notice system, or > even the current edit-at-will system. Most wikis should have > such a problem!! :^) I think a warning is acceptable for most wikis. I think the option should still be there to lock pages during editing as well where social problems cannot be avoided or you want to ensure there are no merge mistakes. I'll try and tidy up what I've done and post a patch to this list soon. Nick From ntrout at rockstarvancouver.com Wed Jan 29 13:19:05 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Wed Jan 29 13:19:05 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD3F5@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FE6@MAILMAN> > -----Original Message----- > From: Florian Festi > [mailto:festifn at rupert.informatik.uni-stuttgart.de] > Sent: January 29, 2003 1:03 PM > > > I is perhaps much easier to use lock files, perhaps > > > data/pages/QuotedPageName/edit.lck . File operations are > atomic and > > > file have a modified time, which could be useful. > > > > One file for each page would probably be easier. Where > would be a good > > place to put these files? Should I create a new directory > called, say, > > data/editlocks? > > I would suggest data/pages/QuotedPageName/edit.lck (You have to create > QuotedPageName if it doen't exist). If I understood the > filesystem layout > right this would be the right place, but perhaps could Juergen Hermann > tell you the correct place insted. Oh I see, sorry I didn't follow you the first time. I did think about that, but it would involve creating a directory for every page, whereas currently only pages with attachments require creation of a directory. > > This is what I have done so far. I wanted to know if there > was a way of > > doing this without altering the Moin code base. Having a > personalised > > site permissions would allow you to lock certain pages to > certain users > > without altering the Moin code. However you can only stop > editing, not > > manage editing, with the current set up. I will look into > simplifying my > > implementation to using individual lock files. > > I don't think this can be done withou touching MoinMoin code. I don't think so either, but there are several ways the problem could be tackled. You could extend the idea to add the facility to lock, or hide page ranges etc (like subscription works). I only really need this lock/edit warning facility currently. I believe someone is working on such a system though. > > > Perhaps it is more worth to put some work in collision resolving. > > > > How would you suggest doing this? > > Do something like CVS does. Apply the right diff and on > collision insert > both version of the problematic lines into the file and tell > the user to > fix the problem. Is it possible to get diff to give you the collisions? Has anybody had a stab at writing some merging code that would try and resolve merges? Nick From jh at web.de Wed Jan 29 14:36:04 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 29 14:36:04 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FE4@MAILMAN> Message-ID: On Wed, 29 Jan 2003 12:26:08 -0800, Nick Trout wrote: >One file for each page would probably be easier. Where would be a good >place to put these files? Should I create a new directory called, say, >data/editlocks? The relevant function is MoinMoin.wikiutil.getPagePath(). See the source for usage examples. >This is what I have done so far. I wanted to know if there was a way of >doing this without altering the Moin code base. Having a personalised >site permissions would allow you to lock certain pages to certain users >without altering the Moin code. However you can only stop editing, not >manage editing, with the current set up. I will look into simplifying my >implementation to using individual lock files. The idea of abusing the Permissions is, well, an abuse. ;) What we could do is to sprinkle core code with different kinds of hook interfaces (which Persmissions already is). i.e. we would have something like config.EditorHook = "MoinMoin.mymodule.MyLockingEditorPlug" and call methods like save(), preview() etc. in those hook classes. This would surely not solve all cases where you need to extend code, but it would help for many common cases. >> Perhaps it is more worth to put some work in collision resolving. > >How would you suggest doing this? Like CVS does it (3-way merging). The idea is already buried somewhere in the wiki. Ciao, J?rgen From jh at web.de Wed Jan 29 14:43:06 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 29 14:43:06 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FE6@MAILMAN> Message-ID: On Wed, 29 Jan 2003 13:21:51 -0800, Nick Trout wrote: >Oh I see, sorry I didn't follow you the first time. I did think about >that, but it would involve creating a directory for every page, whereas >currently only pages with attachments require creation of a directory. You obviously missed the addition of "last-edited". :) See my other msg for the relevant helper function. Ciao, J?rgen From noreply at sourceforge.net Wed Jan 29 14:49:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 29 14:49:03 2003 Subject: [Moin-devel] [ moin-Feature Requests-585211 ] parser plugins Message-ID: Feature Requests item #585211, was opened at 2002-07-23 03:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=585211&group_id=8482 Category: None Group: None Status: Open Priority: 5 Submitted By: Brian P Templeton (plovre) >Assigned to: J?rgen Hermann (jhermann) Summary: parser plugins Initial Comment: Similar to action and macro plugins. This can be done easily by adding plugin-loading code to Page.py (cf. wikiaction.py). ---------------------------------------------------------------------- >Comment By: J?rgen Hermann (jhermann) Date: 2003-01-29 23:53 Message: Logged In: YES user_id=39128 His (worth-while) point is that plugin support is not orthogonal and currently only implemented for macros and actions, while it should also work with at least parsers and processors (and possibly formatters). plugin == extensions not living in the installed MoinMoin package, but in an instance's data directory ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2003-01-02 20:11 Message: Logged In: YES user_id=100649 #format python (set a parser for a whole page) {{{!#gnuplot ... }}} (set a processor for some code) If I did not miss anything in the feature request, this should be deleted, because the features are there meanwhile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=585211&group_id=8482 From jh at web.de Wed Jan 29 15:00:03 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 29 15:00:03 2003 Subject: [Moin-devel] Enhanced SysInfo macro In-Reply-To: Message-ID: On Wed, 8 Jan 2003 13:15:37 +0100 (MET), Florian Festi wrote: >I slightly modified the Sysinfo macro. It now also shows the size of all >pages in bytes. Added, using sane code. ;) Ciao, J?rgen From noreply at sourceforge.net Wed Jan 29 15:08:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 29 15:08:06 2003 Subject: [Moin-devel] [ moin-Bugs-664583 ] typo on default page Message-ID: Bugs item #664583, was opened at 2003-01-08 20:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664583&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chuck Adams (skeptopotamus) Assigned to: Nobody/Anonymous (nobody) Summary: typo on default page Initial Comment: The home page in the default install reads: To create you own templates, add a page with a name ending in Template. It should be "To create your own templates" ... Normally I wouldn't point out typos in pages, being such little things as they are, but this is on the home page of the default install, and it's hardwired into the source in Page.py at that. I want to pitch moin to the suits to use for knowledge engineering, but I don't want them to see a defect on the front page... ---------------------------------------------------------------------- >Comment By: J?rgen Hermann (jhermann) Date: 2003-01-30 00:12 Message: Logged In: YES user_id=39128 fixed some time ago ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=664583&group_id=8482 From jh at web.de Wed Jan 29 15:13:03 2003 From: jh at web.de (Juergen Hermann) Date: Wed Jan 29 15:13:03 2003 Subject: [Moin-devel] Xml Pages In-Reply-To: <1042057207.2704.77.camel@kkinder> Message-ID: On 08 Jan 2003 14:20:07 -0600, Ken Kinder wrote: >Is it just me or is the xslt processor for 4suite built against an >extremely old version of 4suite? Has anyone been using this or is it >maintained? Well, besides 0.12 being in alpha for a long time now, there is also the problem that newer 4Suite versions do not work with Python 2.0. All in all, the support is not abandoned, but also fixing it is not too high a priority right now. So far, it's been my toy pretty much. If more children claim an interest on it, prios might change. :) Ciao, J?rgen From ntrout at rockstarvancouver.com Wed Jan 29 15:17:06 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Wed Jan 29 15:17:06 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD3FB@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FE9@MAILMAN> > From: jh at web.de [mailto:jh at web.de] > Sent: January 29, 2003 2:42 PM > > You obviously missed the addition of "last-edited". :) What is that? Is that a new feature? > See my other msg for the relevant helper function. Thanks. From emailgroup66578 at yahoo.com Wed Jan 29 18:09:04 2003 From: emailgroup66578 at yahoo.com (dariah ) Date: Wed Jan 29 18:09:04 2003 Subject: [Moin-devel] >>Last Chance...15.2 MILLION OPT-IN EMAIL ADDRESSES...PLUS $2,000 IN FREE EMAIL MARKETING SOFTWARE! Message-ID: WOULD YOU LIKE TO HAVE YOUR MESSAGE SEEN BY OVER 15.2 MILLION OPT-IN, TARGETED PEOPLE DAILY? Below contains all the information you will ever need to market your product or service on the Internet. If you have a product, service, or message that you would like to get out to Thousands, Hundreds of Thousands, or even Millions of people, you have several options. Traditional methods include print advertising, direct mail, radio, and television advertising. They are all effective, but they all have two catches: They're EXPENSIVE and TIME CONSUMING. Not only that, you only get ONE SHOT at making your message heard by the right people. Also, Internet Search Engine Submissions, Classified Ads, Newsgroup Postings simply DO NOT WORK effectively. Now this has all changed! Thanks to the top programmers in the world and their NEW EMAIL TECHNOLOGY, You can send millions of email messages daily for FREE...Without getting terminated from your current Internet connection! It's very simple to do and you can be increasing your sales within minutes of installing this new extraordinary software! Besides...It's the only real way to advertise on the Internet that works...Period! >>>WE WILL SUPPLY YOU WITH OVER 15.2 MILLION OPT-IN EMAIL ADDRESSES TO GET YOU STARTED RIGHT AWAY! >>>PLUS FREE EMAIL ADDRESS DOWNLOADS FOR LIFE! >>>ALSO, YOU WILL RECEIVE $2,000 WORTH OF EMAIL MARKETING SOFTWARE FREE! Including...... BROADCAST EMAIL SENDING SOFTWARE...(send millions of email advertisements daily with a few clicks of your mouse, without getting your ISP trerminated. We used the same software to send you this email) EMAIL EXTRACTION SOFTWARE...(retrieve new targeted email addresses daily. Hundreds of thousands of them) LIST MANAGEMENT SOFTWARE...(keep your lists clean, opt-in and manage all your remove requests, leads, sales etc...) and much...much more! Hurry...This extraordinary offer ends at midnight tonight! To find out more information, Do not respond by email. Instead, click on the link below or copy and paste the exact web site address below into your web browser. http://www.vvorldvvideventures.com/504305/addresses.htm We can help you succeed in your online advertising venture. Email Marketing Group ______________________________________________________ Want to be removed from our email list? You were sent this email because you used our Opt-in service. We hope you enjoy reading our messages. However, if you'd rather not receive future e-mails from us, Click on the link below http://www.vvorldvvideventures.com/504305/romove.htm Thank you for your cooperation _______________________________________________________ From ntrout at rockstarvancouver.com Wed Jan 29 19:28:03 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Wed Jan 29 19:28:03 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD3FA@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FED@MAILMAN> > From: moin-devel-admin at lists.sourceforge.net > [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of > Juergen Hermann > Sent: January 29, 2003 2:36 PM > On Wed, 29 Jan 2003 12:26:08 -0800, Nick Trout wrote: > > >One file for each page would probably be easier. Where would > be a good > >place to put these files? Should I create a new directory > called, say, > >data/editlocks? > > The relevant function is MoinMoin.wikiutil.getPagePath(). See > the source > for usage examples. Ah that is not in my version. I updated from a CVS tar a couple of weeks ago I think. I'll get latest tomorrow. > >This is what I have done so far. I wanted to know if there > was a way of > >doing this without altering the Moin code base. Having a personalised > >site permissions would allow you to lock certain pages to > certain users > >without altering the Moin code. However you can only stop > editing, not > >manage editing, with the current set up. I will look into > simplifying my > >implementation to using individual lock files. > > The idea of abusing the Permissions is, well, an abuse. ;) I don't understand how that is abusing the Permissions. I thought the whole point is that you just derive your own ones and attach them to a user and this could be altered per site. Currently you can't really do much with the permissions, just find out if someone may read or edit the site and it looks like this pretty much has so be set on construction because nothing is passed to the "may" permission object to be able to alter its behaviour at runtime. > What we could do is to sprinkle core code with different > kinds of hook > interfaces (which Persmissions already is). > > i.e. we would have something like config.EditorHook = > "MoinMoin.mymodule.MyLockingEditorPlug" > > and call methods like save(), preview() etc. in those hook classes. > > This would surely not solve all cases where you need to > extend code, but > it would help for many common cases. This is what I came up with as well. How useful would it be though. Just to lock pages is a matter of reading and writing a lock file, which could be patched into PageEditor. It might be nice to have the facility to use Permissions to do more complicated behaviour but its not really necessary. It would be nice to be able to set different levels of access e.g. Administrator can add new users and edit anything. Manager can read, edit and create pages. Editor can read and edit pages but can't create. Reader can only read pages. You could block anonymous users and have them apply to the admin for an id to restrict access to sensitive information. This level of functionality probably goes against wiki simplicity and ethos but there are situations where it would be useful so you can manage the flow of information. I'm not suggesting these changes for this simple feature I'd like to add now but they'd be nice for the future. > >> Perhaps it is more worth to put some work in collision resolving. > > > >How would you suggest doing this? > > Like CVS does it (3-way merging). The idea is already buried > somewhere in > the wiki. I'd rather warn people a page is busy. Any merge could create a right mess if there are extensive edits and someone will have to sort it out. From magnus at thinkware.se Thu Jan 30 06:42:05 2003 From: magnus at thinkware.se (Magnus Lycka) Date: Thu Jan 30 06:42:05 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FED@MAILMAN> References: <41647A6597ADD611803C005004D19FD23DD3FA@MAILMAN> Message-ID: <5.1.0.14.0.20030130130919.02c63ec8@www.thinkware.se> At 19:30 2003-01-29 -0800, Nick Trout wrote: >It would be nice to be able to set different levels of access e.g. >Administrator can add new users and edit anything. >Manager can read, edit and create pages. >Editor can read and edit pages but can't create. >Reader can only read pages. Aren't you beginning to make MoinMoin into a Content Management System? It is after all a Wiki System. Perhaps you should use Plone or something like that instead? ( www.plone.org ) Somehow, for the kind of users you seem to have in mind, I feel that Wiki isn't the right thing. But of course, you know that better than I do. Used right, noone will loose editing in a wiki. If someone else beat you to it, you will have to do some manual work, but you have your edited content, you just have to merge it, and there are tools that will indicate exactly what the other guy modified, so you should be able to do these things. If this happens often, the page should be refactored into several smaller pages. This is not for everybody... To quote http://www.c2.com/cgi/wiki?WhyWikiWorks "Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts. If it doesn't appeal, then don't participate, which leaves those of us who read and write to get on with rational discourse." -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From ntrout at rockstarvancouver.com Thu Jan 30 12:18:22 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Thu Jan 30 12:18:22 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD404@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FEE@MAILMAN> > From: Magnus Lycka [mailto:magnus at thinkware.se] > Sent: January 30, 2003 6:41 AM > At 19:30 2003-01-29 -0800, Nick Trout wrote: > >It would be nice to be able to set different levels of access e.g. > >Administrator can add new users and edit anything. > >Manager can read, edit and create pages. > >Editor can read and edit pages but can't create. > >Reader can only read pages. > > Aren't you beginning to make MoinMoin into a Content Management > System? It is after all a Wiki System. Perhaps you should use Plone > or something like that instead? ( www.plone.org ) I did look at plone for my home site as I wanted to restrict access. Plone is built on Zope though which is way to complicated for what I want. I just don't have time to learn it. Thanks for your suggestion though, you are right that would be a better solution for a CMS. I'd probably go with some PHP solution if I went this way. > Somehow, for the kind of users you seem to have in mind, I feel that > Wiki isn't the right thing. But of course, you know that better than I > do. There are certain things that wikis probably arent good for. I did try and coordinate an event by having people alter a wiki page to insert various details. This was a minor disaster. Everyone kept losing their changes because they tried to change pages simultaneously and only found out the details couldn't be entered *after* the changes. This does not encourage new users. With hindsight, this was a bad use of the wiki and a mistake on my part. With a feature to warn people that a page is currently being edited the whole process could have been smoother, hence my suggested change. > Used right, noone will loose editing in a wiki. If someone else beat > you to it, you will have to do some manual work, but you have your > edited content, you just have to merge it, and there are tools that > will indicate exactly what the other guy modified, so you should be > able to do these things. If this happens often, the page should be > refactored into several smaller pages. This is not for everybody... > > To quote http://www.c2.com/cgi/wiki?WhyWikiWorks > > "Wiki is not WysiWyg. It's an intelligence test of sorts to be able > to edit a wiki page. It's not rocket science, but it doesn't appeal > to the VideoAddicts. If it doesn't appeal, then don't participate, > which leaves those of us who read and write to get on with rational > discourse." I take your point but it would be nice to know you face a possible collision. It would be nice if the wiki were "polite" and told you you might have to do some work to merge stuff because someone is currently editing a page. And, what if you were editing a page when someone *did* refactor and cut a page up. Your edits would be dispersed all over the place. I'm a fan of wikis and there are tonnes of them out there and they are all different. I really like Moin, since its written in Python and its well engineered. I have set two up (both Moin), at different companies and I find users are slow to buy in (but eventually do once useful information appears) and a constant complaint has been that they lose changes and are discouraged. One reason is bugs in IE and loses changes in an edit window whilst browsing in another window. Another reason is someone editing a page whilst someone else is editing it. I'm trying to create an environment, as I'm sure everyone else who has installed a wiki has, where people want to contribute and feel constructive. This warning feature is a little niggle which I think everyone would benefit from. I don't want to be too instrusive in the implementation of this feature, hence I'm asking what the minimum changes would have to be, or even not modifying the base at all (which doesn't seem possible). Moin seems pretty polite in other respects, hopefully this will round it off a little more. I've probably commented a little too much, I think you were only criticising the CMS additions! :-) Regards, Nick From magnus at thinkware.se Thu Jan 30 19:47:01 2003 From: magnus at thinkware.se (Magnus Lycka) Date: Thu Jan 30 19:47:01 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FEE@MAILMAN> References: <41647A6597ADD611803C005004D19FD23DD404@MAILMAN> Message-ID: <5.1.0.14.0.20030131042539.02c7a688@www.thinkware.se> At 12:20 2003-01-30 -0800, Nick Trout wrote: >I take your point but it would be nice to know you face a possible >collision. It would be nice if the wiki were "polite" and told you you >might have to do some work to merge stuff because someone is currently >editing a page. And, what if you were editing a page when someone *did* >refactor and cut a page up. Your edits would be dispersed all over the >place. But I think this works! When you try to save it says: --- Sorry, someone else saved the page while you edited it. Please do the following: Use the back button of your browser, and cut&paste your changes from there. Then go forward to here, and click EditText again. Now re-add your changes to the current page contents. Do not just replace the content editbox with your version of the page, because that would delete the changes of the other person, which is excessively rude! --- You can obviously change this to be more elaborate. Go back and copy your text. Paste it into your favourite editor. Click on the 3D glasses to see what was changed by the other party. Figure out what to do now. click on the edit icon, and fix the text based on current content and what you placed in your editor. I realize what you say, warn already when the editing starts, but that has several disadvantages. Obviously the number of "start edit" events can be bigger than the number of "saves". People start editing but change their mind, get lost in surfing, or just open the page to see how you construct a table of contents or whatever. In these cases you will warn people for no reason. Also, if you start edit, and then I start editing, finish before you and try to save, you will either have a hard lock that prevents me from saving, completely disabling parallel work, or I will be able to give you a surprise when you try to save...and we will be back at todays situation. Perhaps the trick is to teach people how to merge. Perhaps there should be a merge tool? > One reason is bugs in IE and loses changes >in an edit window whilst browsing in another window. Really? Yet another reason to use Opera or Mozilla... I guess switching browser is the only way to change that. Also, teach people to do many small changes rather than few big ones, even if the page might be in a state they don't like for a minute or three. >Another reason is >someone editing a page whilst someone else is editing it. Which can be handled... I have a feeling that people who are able to live with Wiki syntax can handle that as well... > I think you were only criticising the CMS additions! Yes... Of course, it's a good thing if software components can be ... well ... components, so that we can pick out features to use in other contexts. A lot of MoinMoin could be useful in a CMS system, or for a generator of static pages etc. -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From noreply at sourceforge.net Thu Jan 30 19:50:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 30 19:50:03 2003 Subject: [Moin-devel] [ moin-Patches-522246 ] Transparently recode localized messages Message-ID: Patches item #522246, was opened at 2002-02-25 00:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=522246&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: J?rgen Hermann (jhermann) Summary: Transparently recode localized messages Initial Comment: Currently, the localized messages will show up incorrectly when the config.encoding is not the encoding of the messages. With this patch, the messages are transparently recoded to the target encoding if Python supports the necessary codecs. With that change, e.g. the German translations will display correctly even if config.encoding is UTF-8. ---------------------------------------------------------------------- >Comment By: J?rgen Hermann (jhermann) Date: 2003-01-31 04:55 Message: Logged In: YES user_id=39128 Added, and lang selection in prefs is unlimited if charset == UTF-8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=522246&group_id=8482 From tw at waldmann-edv.de Fri Jan 31 04:04:03 2003 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Fri Jan 31 04:04:03 2003 Subject: [Moin-devel] Page Permissions References: <41647A6597ADD611803C005004D19FD23DD404@MAILMAN> <5.1.0.14.0.20030131042539.02c7a688@www.thinkware.se> Message-ID: <3E3A611F.2080402@waldmann-edv.de> Hi Magnus, > You can obviously change this to be more elaborate. Go back and copy > your text. Paste it into your favourite editor. Click on the 3D glasses > to see what was changed by the other party. Figure out what to do now. And if it is too much for you: kill yourself ;) > I realize what you say, warn already when the editing starts, but that > has several disadvantages. Obviously the number of "start edit" events > can be bigger than the number of "saves". People start editing but change > their mind, get lost in surfing, or just open the page to see how you > construct a table of contents or whatever. Indeed! I would pledge for a action=raw (maybe instead of action=xml). I use edit very often just to see source code (and being lazy, I often don't want to manually type "?action=raw" into the URL line). So I think this action=raw icon (calling it RAW or SRC or ...?) would really help with that I personally did never make any use ot of this XML icon. If others also rarely use it, it maybe should be replaced by this "show page source icon". After a while I think these "edits to see source" would get much less. > In these cases you will warn > people for no reason. Also, if you start edit, and then I start editing, > finish before you and try to save, you will either have a hard lock that > prevents me from saving, Personally I don't want hard locks. They might do more harm than make things better. > completely disabling parallel work, or I will > be able to give you a surprise when you try to save...and we will be back > at todays situation. Yes. But you have been warned. And you being a nice guy, you will not impose much work on other people merging their stuff if you don't feel really necessary. > Perhaps the trick is to teach people how to merge. > Perhaps there should be a merge tool? Yes, but that is not an alternative, but an additional thing. > Also, teach people to do many small changes rather > than few big ones, even if the page might be in a state > they don't like for a minute or three. "Backup often" (wiki: save often) is a good idea anyway. Some browsers and also some so-called operating systems tend to crash. Connections get terminated, etc... greetings, Thomas From tw at waldmann-edv.de Fri Jan 31 04:27:12 2003 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Fri Jan 31 04:27:12 2003 Subject: [Moin-devel] Page Permissions References: <41647A6597ADD611803C005004D19FD2396FEE@MAILMAN> Message-ID: <3E3A66B8.3030101@waldmann-edv.de> Hi Nick, >various details. This was a minor disaster. Everyone kept losing their >changes because they tried to change pages simultaneously and only found >out the details couldn't be entered *after* the changes. This does not >encourage new users. > Yes. "Warning" as you intend to do is a good thing, IMHO. One can also try to reduce colisions by making pages not too long, so using a finer granularity is also maybe part of a solution. Using linuxwiki I also try not edit pages that have been edited less than 15minutes before. Often people do a 2nd, 3rd, etc. edit. >And, what if you were editing a page when someone *did* >refactor and cut a page up. Your edits would be dispersed all over the >place. > That's really bad. I had that some times and it is not fun, simply much work either gets lost or done again. >This warning feature is a little niggle which I think >everyone would benefit from. > This has been on my wish list for long and I would definitely use this for all wikis on wikiwikiweb.de. Although there are other things that can be done additionally (like a great merging support function), this is a simple thing that can be done NOW and that'll work in an easy way. >I think you were only criticising the CMS additions! > I don't want to change wiki / moinmoin into a CMS either. Standard CMSs are usually fscking complicated and I don't want that. But I would really like some SIMPLE functions for ACLs (see MoinMoin:AccessControlList(s?)), to be able to use it for private or confidential stuff on the web. Please add your ideas there, how to implement that best. Thomas From magnus at thinkware.se Fri Jan 31 06:44:09 2003 From: magnus at thinkware.se (Magnus Lycka) Date: Fri Jan 31 06:44:09 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <3E3A66B8.3030101@waldmann-edv.de> References: <41647A6597ADD611803C005004D19FD2396FEE@MAILMAN> Message-ID: <5.1.0.14.0.20030131153545.02ce9a80@www.thinkware.se> At 13:06 2003-01-31 +0100, Thomas Waldmann wrote: >But I would really like some SIMPLE functions for ACLs (see >MoinMoin:AccessControlList(s?)), to be able to use it for private or >confidential stuff on the web. Agreed. Personally I'd be happy with being able to restrict read and write for "non-members". It's fairly simple to do this globally though, without big changes in MoinMoin, and to do it on a page level you can set up three wikis: a public, a protected and a private. Then you simply use InterWiki to address between them. That way you will have to be explicit about addressing, but I think that is a GoodThing. When you have full permissions it's very easy to publish links to restricted pages, and people won't be able to follow links as you intended. -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From magnus at thinkware.se Fri Jan 31 07:03:04 2003 From: magnus at thinkware.se (Magnus Lycka) Date: Fri Jan 31 07:03:04 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <3E3A611F.2080402@waldmann-edv.de> References: <41647A6597ADD611803C005004D19FD23DD404@MAILMAN> <5.1.0.14.0.20030131042539.02c7a688@www.thinkware.se> Message-ID: <5.1.0.14.0.20030131154405.02ceaeb0@www.thinkware.se> At 12:42 2003-01-31 +0100, Thomas Waldmann wrote: >So I think this action=raw icon (calling it RAW or SRC or ...?) would >really help with that I'm sure you can fix that on your wikis. [I start editing after you, and save first in "warn when you start to edit" scenario.] >Yes. But you have been warned. I know, but you haven't, and you are the one who will have to deal with it. (Unless you just paste over my edits.) But even then, there is a history mechanism to retrieve the pasted over data. There should *never* have to be loss of saved MoinMoin data. >And you being a nice guy, you will not impose much work on other people >merging their stuff if you don't feel really necessary. But I don't know if you *will* save anything. And I surely don't know if it will cause any difficult to resolve conflicts. Nice guy or not. I just had this tiny change I wanted to make right now, since it just popped up, and I don't want to make this into a big case that I have to schedule in my Filofax. The simplicity is one of the main aspects of a Wiki. If YOU want to make a big change in a page, and want it to be left alone while you edit, why don't you just say so? Just place the text = HEY! I'm making big changes in this page right now = == Please leave it alone for a while. /Thomas == Then you save it. Then you open it again. No programming needed. If you feel a desire to change the code, make a new EditTextWithWarning link that will make this happen in one step. You click on that, the page will be updated with the text = WARNING: Currently edited by UserName since 14:30 Jan 31 = and saved. Then it will be opened for editing again. There might be a check to see that there isn't already such a Warning notice in the page... I don't feel that MoinMoin should be turned into some kind of ClearCase. I still feel that if this becomes a common problem in a Wiki, you either use it the wrong way or use it for the wrong purpose. >"Backup often" (wiki: save often) is a good idea anyway. >Some browsers and also some so-called operating systems tend to crash. >Connections get terminated, etc... Certainly. But obviously this is difficult to learn for some. The best way to teach them is probably to toggle the power now and then. ;) Maybe wikis work well among extreme programmers because they have learnt to do things in small steps. That's how they code, and I guess that's how they write. -- Magnus Lycka, Thinkware AB Alvans vag 99, SE-907 50 UMEA, SWEDEN phone: int+46 70 582 80 65, fax: int+46 70 612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From jh at web.de Fri Jan 31 08:49:07 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 08:49:07 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <5.1.0.14.0.20030131154405.02ceaeb0@www.thinkware.se> Message-ID: On Fri, 31 Jan 2003 16:02:42 +0100, Magnus Lycka wrote: >At 12:42 2003-01-31 +0100, Thomas Waldmann wrote: >>So I think this action=raw icon (calling it RAW or SRC or ...?) would >>really help with that > >I'm sure you can fix that on your wikis. Indeed, you can simply copy the default from config.py and change it. I hope we'll get skins into 1.2, then this'll get nicer (no html code in the icons list, only the raw data, i.e. img & link data). BTW, Magnus, why do you discuss new features when you run 0.11 or something, with ugly diffs, no preview, ...? [SCNR ;) ] And will we see you on EP2003? Ciao, J?rgen From tim at bird.org Fri Jan 31 09:38:07 2003 From: tim at bird.org (Tim Bird) Date: Fri Jan 31 09:38:07 2003 Subject: [Moin-devel] Skins... Message-ID: <20030131173751.64670.qmail@web20803.mail.yahoo.com> Juergen mentioned something about skins, and someone else mentioned something about access control, so I thought I would throw some ideas out. I have been wanting to do something with skins for a long time. Before I stumbled onto MoinMoin, I had developed my own very simple web-based database system that allowed you to enter the html templates for the data entry and output of the system, in the system itself. So, the system could be customized like so: it would present a form with header, per-record template, and tail that you could fill out. The way the system worked syntactically was that it built the widgets or data output strings for you, and you could reference them with %(namedvar)s format strings inside your template. It worked very well, but for other reasons, I eventually gave up on this system. For example, if you gave it the template: """Enter the data for the address book:
  • Name: %(namewidget)s
  • Phone: %(phonewidget)s
""" It would supply the widgets for that form by creating the strings for them in a dictionary, and just formatting the template string with that dictionary. For record output, the thing worked similarly: """%(recordIndex). %(name)s has phone number %(phone)s""" I have been wanting to do a similar system for MoinMoin templates, including putting the template itself on a special MoinMoin page (or maybe as part of a user's preferences) so it could be customized online. One problem with this is you end up having to pre-generate all the possible elements a template might want to reference, even if they're not used by a particular template. (You have to put them in the dictionary in case they're referenced.) Another way to do this is to scan the template ahead of time and only generate the strings for items that are referenced. Or, to be even more fancy, you can create a class that looks like a dictionary and on calls to the the __getitem__ function dynamically generate on the fly whatever content is requested (defaulting to statically configured elements if the user hasn't provided a generator function.) I'm not sure how all this would work with regards to XML output, so I've hesitated to dive into it. Now, on to something related to access control. I've been thinking about skins a lot lately, because I'm facing a problem where I may be forced to put my materials on a web site where I don't have the capability to run CGIs. So I'm considering a structure where I statically generate the web pages at periodic intervals, using moin-dump, and post the static HTML instead. So I end up with static HTML pages on my public web site, that are obviously read-only to the anonymous user. I plan to put a link on these pages, back to a separate (private) site where the MoinMoin is "live" in its editable form (and that whole site is covered by a global password I share with friends.) [Don't ask why I don't just direct people to this site in the first place -- it's a long story!] Thus, the static site is a continual mirror of the dynamic site, which is editable (but only if you have a password). The skins come into the game because I had problems generating some of the header and tail pieces when in "moin-dump" mode, and so started looking at this part of the system. Please let me know your comments. If Juergen is already working on skins I don't want to start a big project like this. (I'm not promising anything - I've been thinking about this for months and haven't found the time to do it, so there's no telling if I'll get to this soon or not.) Regards, Tim Bird ===== Tim Bird Embedded Linux Consultant tim at bird.org Tim Bird Consulting 801-221-5852 http://www.bird.org/ From tw at waldmann-edv.de Fri Jan 31 10:44:03 2003 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Fri Jan 31 10:44:03 2003 Subject: [Moin-devel] Page Permissions References: <41647A6597ADD611803C005004D19FD2396FEE@MAILMAN> <5.1.0.14.0.20030131153545.02ce9a80@www.thinkware.se> Message-ID: <3E3AC34C.5000509@waldmann-edv.de> >> But I would really like some SIMPLE functions for ACLs (see >> MoinMoin:AccessControlList(s?)), to be able to use it for private or >> confidential stuff on the web. > > Agreed. Personally I'd be happy with being able to restrict > read and write for "non-members". It's fairly simple to do > this globally though, without big changes in MoinMoin, and > to do it on a page level you can set up three wikis: ... I don't want to set up 3 wikis, if I only need some (3 ;) protected pages. I also don't want to treat anybody special by moin's securitypolicy by adding his id to moin_config.py. That all would be overkill due to missing functionality. greetings, -- Thomas Waldmann (Waldmann EDV) www: www.waldmann-edv.de From tw at waldmann-edv.de Fri Jan 31 10:56:05 2003 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Fri Jan 31 10:56:05 2003 Subject: [Moin-devel] Page Permissions References: <41647A6597ADD611803C005004D19FD23DD404@MAILMAN> <5.1.0.14.0.20030131042539.02c7a688@www.thinkware.se> <5.1.0.14.0.20030131154405.02ceaeb0@www.thinkware.se> Message-ID: <3E3AC611.9030405@waldmann-edv.de> > [I start editing after you, and save first in "warn when you start to > edit" scenario.] >> Yes. But you have been warned. > I know, but you haven't, and you are the one who will > have to deal with it. Uhm, yes. That's a problem still. So people have to behave social and kind. They should do anyway in a wiki. > = HEY! I'm making big changes in this page right now = > == Please leave it alone for a while. /Thomas == Yes, I sometimes already did that. But sometimes you don't PLAN to do long and complex changes. But then you decide to do while editing and ... Therefore, some standard behaviour you don't have to PLAN would be nice. > Then you save it. Then you open it again. No programming > needed. If you feel a desire to change the code, make a > new EditTextWithWarning link that will make this happen > in one step. You click on that, the page will be updated > with the text > > = WARNING: Currently edited by UserName since 14:30 Jan 31 = > > and saved. Then it will be opened for editing again. There > might be a check to see that there isn't already such a > Warning notice in the page... That wouldn't be that much different from the lock approch, except that the "lock" is text content that has to be removed again. If you are not kind, you can also cause trouble by going in between anyway. > I don't feel that MoinMoin should be turned into some kind > of ClearCase. I still feel that if this becomes a common > problem in a Wiki, you either use it the wrong way or use > it for the wrong purpose. I don't know clearcase. I am NOT for hard locks and locking people out from editing, because in case of some failure (human, machine, bad guy, whatever) that can be really bad and annoying. > Certainly. But obviously this is difficult to learn > for some. The best way to teach them is probably to > toggle the power now and then. ;) Most people don't need that. They use windows, that's even worse. greetings, Thomas From ntrout at rockstarvancouver.com Fri Jan 31 11:00:07 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Fri Jan 31 11:00:07 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD408@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FF4@MAILMAN> > From: Magnus Lycka [mailto:magnus at thinkware.se] > Sent: January 30, 2003 7:46 PM > To: Nick Trout; moin-devel at lists.sourceforge.net > Subject: RE: [Moin-devel] Page Permissions > > At 12:20 2003-01-30 -0800, Nick Trout wrote: > >I take your point but it would be nice to know you face a possible > >collision. It would be nice if the wiki were "polite" and > told you you > >might have to do some work to merge stuff because someone is > currently > >editing a page. And, what if you were editing a page when > someone *did* > >refactor and cut a page up. Your edits would be dispersed > all over the > >place. > > But I think this works! When you try to save it says: It tells you *after* your editing is done that someone else came in and saved before you. I want to be notified *before* I start editing that someone else is editing the page I am looking at. This way I have the choice of (being rude and) trying to get my edit in first or coming back later. Also, a lot of inexperienced wiki users will just abandon their changes and complain when this message appears. Not all wiki users are programmers (and good at merging) and not everyone will painstakingly go through and merge changes in. I want to encourage people to use the wiki. I think think people have a right to feel short changed if they contribute to something and the wiki lets them down saying: > --- > Sorry, someone else saved the page while you edited it. > > Please do the following: Use the back button of your browser, > and cut&paste > your changes from there. Then go forward to here, and click > EditText again. > Now re-add your changes to the current page contents. > > Do not just replace the content editbox with your version of > the page, > because that would delete the changes of the other person, which is > excessively rude! > --- > You can obviously change this to be more elaborate. Go back and copy > your text. Paste it into your favourite editor. Click on the > 3D glasses > to see what was changed by the other party. Figure out what to do now. > click on the edit icon, and fix the text based on current content and > what you placed in your editor. I though wikis were supposed to be simple. Again, you are programmer, great you understand how to do that. Not everyone who uses a wiki is a programmer. > Perhaps the trick is to teach people how to merge. > Perhaps there should be a merge tool? Ok, this was mentioned. Does anyone have any ideas or is there any code anywhere? > Really? Yet another reason to use Opera or Mozilla... > I guess switching browser is the only way to change > that. Also, teach people to do many small changes rather > than few big ones, even if the page might be in a state > they don't like for a minute or three. Fair enough, but I want to avoid a "competitive" atmosphere to > Of course, it's a good thing if software components can be > ... well ... components, so that we can pick out features > to use in other contexts. A lot of MoinMoin could be useful > in a CMS system, or for a generator of static pages etc. Yes. I like moin and it's a lot more modular than a lot of wikis out there. TBH since I started using Moin I've thought of a lot more things that I can do with it and I am starting to see it more as a CMS. Although I like it the way it is, simple and flexible, and would like to see it more customisable. Its nice that it its written in Python so you can write nice macros to link your intranet together and do other processing. Nick From brian at dorseys.org Fri Jan 31 11:35:05 2003 From: brian at dorseys.org (Brian Dorsey) Date: Fri Jan 31 11:35:05 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD2396FF4@MAILMAN> References: <41647A6597ADD611803C005004D19FD23DD408@MAILMAN> <41647A6597ADD611803C005004D19FD2396FF4@MAILMAN> Message-ID: <20030131194546.GA23377@dorseys.org> On Fri, Jan 31, 2003 at 11:03:08AM -0800, Nick Trout wrote: > > Perhaps the trick is to teach people how to merge. > > Perhaps there should be a merge tool? > > Ok, this was mentioned. Does anyone have any ideas or is there any code > anywhere? I've never tried to use it, but the difflib module is included in Python 2.1 and higher. Take care, -Brian From ntrout at rockstarvancouver.com Fri Jan 31 11:40:03 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Fri Jan 31 11:40:03 2003 Subject: [Moin-devel] Page Permissions In-Reply-To: <41647A6597ADD611803C005004D19FD23DD40B@MAILMAN> Message-ID: <41647A6597ADD611803C005004D19FD2396FF6@MAILMAN> > From: moin-devel-admin at lists.sourceforge.net > [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of > Thomas Waldmann > Sent: January 31, 2003 3:42 AM > I personally did never make any use ot of this XML icon. If > others also > rarely use it, it maybe should be replaced by this "show page > source icon". > After a while I think these "edits to see source" would get much less. Yes I agree. I don't know what the XML icon is for either! Changing it to view source is a good idea. Perhaps we could even colour code the source so users can see which are the various formatting characters - easier to learn and easier to read. > > Also, teach people to do many small changes rather > > than few big ones, even if the page might be in a state > > they don't like for a minute or three. > > "Backup often" (wiki: save often) is a good idea anyway. > Some browsers and also some so-called operating systems tend to crash. > Connections get terminated, etc... This warning feature tells you when you started editing the page so you know how many minutes you have been editing the page. > [mailto:moin-devel-admin at lists.sourceforge.net] On Behalf Of > Thomas Waldmann > Sent: January 31, 2003 4:06 AM > To: moin-devel at lists.sourceforge.net > Subject: Re: [Moin-devel] Page Permissions > One can also try to reduce colisions by making pages not too long, so > using a finer granularity is also maybe part of a solution. True, but if you want 10 people to enter their details... I could have a page for each entry but that's overkill. I should probably have made up some kind of form macro which saved its entry to another page. > Using linuxwiki I also try not edit pages that have been edited less > than 15minutes before. Often people do a 2nd, 3rd, etc. edit. That's a good idea. > Although there are other things that can be done additionally (like a > great merging support function), this is a simple thing that > can be done > NOW and that'll work in an easy way. Maybe once this is done I could start looking at a merge solution. I've just got a little more testing to do and I'll post the patch. Should I post it to the list? > I don't want to change wiki / moinmoin into a CMS either. > Standard CMSs > are usually fscking complicated and I don't want that. I agree. Plone was far too complicated and the portal managers like Nuke don't look like, or do what I want, they are too rigid. Has anyone found any good Python ones, or simpler more flexible PHP ones? > But I would really like some SIMPLE functions for ACLs (see > MoinMoin:AccessControlList(s?)), to be able to use it for private or > confidential stuff on the web. Please add your ideas there, how to > implement that best. I like your ideas on ACLs. Simple, effective. Perhaps you should write it up for the list. > Thomas Waldmann > Sent: January 31, 2003 10:41 AM > To: moin-devel at lists.sourceforge.net > Subject: Re: [Moin-devel] Page Permissions > > Agreed. Personally I'd be happy with being able to restrict > > read and write for "non-members". It's fairly simple to do > > this globally though, without big changes in MoinMoin, and > > to do it on a page level you can set up three wikis: ... > > I don't want to set up 3 wikis, if I only need some (3 ;) > protected pages. I agree, its excessively complicated. > I also don't want to treat anybody special by moin's > securitypolicy by > adding his id to moin_config.py. > That all would be overkill due to missing functionality. I agree, that's the only way that I can see that you can have per user permissions which is "hardcoded" and not very satisfactory. > Thomas Waldmann > Sent: January 31, 2003 10:53 AM > To: moin-devel at lists.sourceforge.net > Subject: Re: [Moin-devel] Page Permissions > > > = HEY! I'm making big changes in this page right now = > > == Please leave it alone for a while. /Thomas == > > Yes, I sometimes already did that. But sometimes you don't PLAN to do > long and complex changes. But then you decide to do while > editing and ... > > Therefore, some standard behaviour you don't have to PLAN > would be nice. I think this is a good point. The wiki is pretty free form. Sometimes you can be browsing around and just see an error and whilst fixing it you start to add comments and maybe someone interrupts you, the phone rings etc. (Currently, with the patch I am doing, if the timer goes past 10 minutes other users will not be warned that you are editing a page, so you may have to merge. ie. you have a limited "grace period" to get your edits in.) regards, Nick From whisper at oz.net Fri Jan 31 12:09:28 2003 From: whisper at oz.net (David LeBlanc) Date: Fri Jan 31 12:09:28 2003 Subject: [Moin-devel] Double posts Message-ID: Am I the only one suddenly seeing all posts coming in duplicate? David LeBlanc Seattle, WA USA From ntrout at rockstarvancouver.com Fri Jan 31 13:39:03 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Fri Jan 31 13:39:03 2003 Subject: [Moin-devel] Function name format Message-ID: <41647A6597ADD611803C005004D19FD23B35D1@MAILMAN> What is the preferred format for function names? def myFunctionName() or def my_function_name() There doesn't seem to be any consistency. Are there any coding guidelines for MoinMoin? Nick From ntrout at rockstarvancouver.com Fri Jan 31 19:12:02 2003 From: ntrout at rockstarvancouver.com (Nick Trout) Date: Fri Jan 31 19:12:02 2003 Subject: [Moin-devel] Edit lock patch Message-ID: <41647A6597ADD611803C005004D19FD23B3655@MAILMAN> Hi, this is the edit locking patch I have been working on. It is a patch of the CVS version from a couple of days ago. (I just did cvs ... diff > file, is this usual way of submitting patches?) I have tested it a little but I don't have time to test any further. Features: * Choose your edit locking type in the config: (default is 'warn 10') config.edit_locking = None | 'lock []' | 'warn []' * None: Edit locking is switched off, Moin is the same as before. * Warn : If you start editing a page and someone tries to edit it within the timeout period, they will receive a big red message saying: "

Another user, %s, started editing this page at %s (%d minutes ago).

Please consider returning to this page at a later time to make your changes and avoid any editing conflicts. Hit the cancel button to exit this page.

" They are free to continue editing if they like and if they save you will still lose your changes, as before. * Lock : The page is locked for minutes after you start editing. Noone else can edit the page whilst you are editing it (and the timeout hasn't run out). * The timeout is reset when you press preview. * In the case of both Warn and Lock, if you cancel editing, or save the page, then the lock is removed. If you wander off a page and do nothing then other users will have to wait for the timeout for whatever message to disappear. You might reduce the timeout to deal with this. Please post any bugs to the list and I'll try and fix any problems next week if I get some time. Regards, Nick -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: d1.txt URL: From jh at web.de Fri Jan 31 21:25:02 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 21:25:02 2003 Subject: [Moin-devel] Double posts In-Reply-To: Message-ID: On Fri, 31 Jan 2003 12:09:49 -0800, David LeBlanc wrote: >Am I the only one suddenly seeing all posts coming in duplicate? Possibly, since I don't get dupes. Maybe you subscribed also with an address that is forwarded to your main account? Check the headers (routes) of two such mails, whether they're identical. Ciao, J?rgen From jh at web.de Fri Jan 31 21:47:04 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 21:47:04 2003 Subject: [Moin-devel] Skins... In-Reply-To: <20030131173751.64670.qmail@web20803.mail.yahoo.com> Message-ID: On Fri, 31 Jan 2003 09:37:51 -0800 (PST), Tim Bird wrote: >I have been wanting to do a similar system for MoinMoin templates, >including putting the template itself on a special MoinMoin page >(or maybe as part of a user's preferences) so it could be customized >online. This complicates things in various ways (security, complexity, performance), although it's of course a nice thing to have. >Or, to be even more fancy, you can create a class that looks like >a dictionary and on calls to the the __getitem__ function dynamically >generate on the fly whatever content is requested This is one of the things I had in mind. >I'm not sure how all this would work with regards to XML output, >so I've hesitated to dive into it. It's rather unrelated, because only the web UI will be skinnable. >Please let me know your comments. If Juergen is already working >on skins I don't want to start a big project like this. (I'm >not promising anything - I've been thinking about this for months >and haven't found the time to do it, so there's no telling if I'll >get to this soon or not.) Well, I wanted this for a long time too, and failed for the same reasons so far. ;) Whatever you do, before anyone starts such a big task, coordinate with me, otherwise we maybe waste efforts because of duplicate work. Ciao, J?rgen From jh at web.de Fri Jan 31 21:47:04 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 21:47:04 2003 Subject: [Moin-devel] Function name format In-Reply-To: <41647A6597ADD611803C005004D19FD23B35D1@MAILMAN> Message-ID: On Fri, 31 Jan 2003 13:48:56 -0800, Nick Trout wrote: >def myFunctionName() > >or > >def my_function_name() > > >There doesn't seem to be any consistency. Are there any coding guidelines >for MoinMoin? The first form is preferred, though the second might appear in source. The current rules are on MoinMoin:MoinDev/CodingStandards. I put more stress on documented, well-structured code than on nit-picking about formatting (except the 4 spaces, no tabs, follow guido's style rule). Ciao, J?rgen From jh at web.de Fri Jan 31 21:53:04 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 21:53:04 2003 Subject: [Moin-devel] Edit lock patch In-Reply-To: <41647A6597ADD611803C005004D19FD23B3655@MAILMAN> Message-ID: On Fri, 31 Jan 2003 19:22:20 -0800, Nick Trout wrote: >Hi, this is the edit locking patch I have been working on. It is a patch of >the CVS version from a couple of days ago. (I just did cvs ... diff > file, >is this usual way of submitting patches?) I have tested it a little but I >don't have time to test any further. Unified diffs are preferred (diff -u). Also, your patch is cluttered with spacing changes like 383c521 < pass --- > pass Try to avoid them, please (I guess they're either removed or added spaces at the line end). I'll add it to the code base. Ciao, J?rgen From jh at web.de Fri Jan 31 21:58:03 2003 From: jh at web.de (Juergen Hermann) Date: Fri Jan 31 21:58:03 2003 Subject: [Moin-devel] Code freeze Message-ID: Hi! To have an even remote chance to finally get a new release out, I'll freeze the code after adding bero's and nick's patches. The only changes after that will be some minor fixes accumulated on my TODO, and bug fixes. During this period, translators get a chance to catch up, and the docs can be updated. After 1.1, I plan to switch to a more date-driven instead of a feature- driven release cycle (i.e. release what's there all 2-3 months). Ciao, J?rgen