From N.F.Brooks at exeter.ac.uk Thu Apr 1 09:29:01 2004 From: N.F.Brooks at exeter.ac.uk (Neil Brooks) Date: Thu Apr 1 09:29:01 2004 Subject: [Moin-devel] Help:Displaying generated chart Message-ID: <204375562.1080844076@D8KY5D0J.ex.ac.uk> Hi, I am working on modifying pagehits.py to use Yasuhi Saito's PyChart rather than gdchart. I also thought that svg (xml) graphics would be neat. I am stuck on the way to display the generated svg data. Do I dump it into a file and set up an img link? If so, where should I store the file? Or do I simply create an inline image by dumping the content straight into the displayed page? If so, I can't seem to create the right html to display the chart. What is the sequence of request.writes() to get the image in the middle of the page? Do I need a macro calling my action? What is the MoinMoin way, Oh learned ones? Neil -- Neil Brooks Small Systems Team Leader IT Services University of Exeter Tel: +44 (0)1392 26 3923 From R.Bauer at fz-juelich.de Thu Apr 1 21:12:00 2004 From: R.Bauer at fz-juelich.de (Reimar Bauer) Date: Thu Apr 1 21:12:00 2004 Subject: [Moin-devel] RE:Help:Displaying generated chart (Neil Brooks) In-Reply-To: References: Message-ID: <200404020720.56032.R.Bauer@fz-juelich.de> > Message: 2 > Date: Thu, 01 Apr 2004 18:27:56 +0100 > From: Neil Brooks > To: moin-devel at lists.sourceforge.net > Subject: [Moin-devel] Help:Displaying generated chart > > Hi, > > I am working on modifying pagehits.py to use Yasuhi Saito's PyChart rather > than gdchart. I also thought that svg (xml) graphics would be neat. > > I am stuck on the way to display the generated svg data. > Do I dump it into a file and set up an img link? If so, where should I > store the file? > > Or do I simply create an inline image by dumping the content straight into > the displayed page? If so, I can't seem to create the right html to display > the chart. What is the sequence of request.writes() to get the image in the > middle of the page? Do I need a macro calling my action? > > What is the MoinMoin way, Oh learned ones? > > Neil Dear Neil I would prefer to have the image stored as file but its only temporary data. You better watch what someone else says to this point. if you take a look into the latex.1.2.1.py you find these lines: (http://moinmoin.wikiwikiweb.de:8000/ ProcessorMarket?action=AttachFile&do=get&target=latex.1.2.1.py) pagename=formatter.page.page_name url=AttachFile.getAttachUrl(pagename,imgname+'.png',request) attach_dir=AttachFile.getAttachDir(pagename,create=1) os.system("%(convert)s -crop 0x0 -density 120x120 %(vartmp)s/%(imgname)s.ps % (outpath)s" % { "convert": config_external_convert, "vartmp": vartmp, "outpath": attach_dir+'/'+imgname+'.png', "imgname": imgname, }) get it in the middle: request.write(formatter.image(src="%s" % url, alt=texstr, align='absmiddle')) Reimar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mikei at kinitos.com Fri Apr 2 09:28:02 2004 From: mikei at kinitos.com (Michael Iles) Date: Fri Apr 2 09:28:02 2004 Subject: [Moin-devel] Archiving email to a Moin wiki In-Reply-To: <49E95F5EE462824597FA4D82F220F5AD0B565E@cinder.toronto.kinitos.com> Message-ID: <200404021727.i32HRDF13775@mandarin.kinitos.com> I'm interested in archiving mail to a Moin wiki and being able to use the wiki's search capabilities on it. Has anyone ever done this? Mike. From nick at rockstarvancouver.com Fri Apr 2 15:29:00 2004 From: nick at rockstarvancouver.com (Nick Trout) Date: Fri Apr 2 15:29:00 2004 Subject: [Moin-devel] Help:Displaying generated chart Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FD30@iggy.rockstarvancouver.com> > admin at lists.sourceforge.net] On Behalf Of Neil Brooks > I am stuck on the way to display the generated svg data. > Do I dump it into a file and set up an img link? If so, where should I > store the file? Here are some examples of embedded SVG: http://www.protocol7.com/svg-wiki/ow.asp?ChartsAndGraphing Personally I'd like to see the charts using the SVG plug in (i.e. rendered in the fly). SVG is getting pretty widely used now. This way you can do interactive charts and they scale and look better when printed. You might also offer the option to render them in PNG if so desired. You could make this an option in the config. Nick From noreply at sourceforge.net Sun Apr 4 14:38:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 14:38:03 2004 Subject: [Moin-devel] [ moin-Patches-875444 ] PageEditor _make_backup fails on Win32 Message-ID: Patches item #875444, was opened at 2004-01-12 16:43 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=875444&group_id=8482 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas Kl?ger (tomy) Assigned to: Nobody/Anonymous (nobody) Summary: PageEditor _make_backup fails on Win32 Initial Comment: Using MoinMoin on Win32: While editing a page, if you preview your changes and then additionally try the spell checker you get an "OSError: [Errno 17] File exists". The problem is that on win32 os.rename does not overwrite a file if it already exists. To attached patch corrects this by removing the old file on win32 before renaming. ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-04 23:37 Message: Logged In: YES user_id=100649 implemented MoinMoin.util.filesys.rename to fix that the fix is in moin--main--1.2 tla branch need testers as I don't have windows if it is still broken, reopen this item ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-03-27 15:49 Message: Logged In: YES user_id=100649 I would like to have a TESTED patch that: * fixes ALL places were os.rename is used * replaces those calls with a call to MoinMoin.util.filesys.rename that handles platform specific stuff as good as possible (and just calls os.rename for every non-broken OS) The patch should be based on latest 1.2.x release or 1.3 devel version. As I can't test it, I can't fix it. ---------------------------------------------------------------------- Comment By: Johannes Berg (johill) Date: 2004-03-10 14:30 Message: Logged In: YES user_id=32619 On Windows NT the python function could use MoveFileEx with some flags to get overwrite behaviour, this is not supported on 9x/ME though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=875444&group_id=8482 From noreply at sourceforge.net Sun Apr 4 15:19:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 15:19:02 2004 Subject: [Moin-devel] [ moin-Feature Requests-916149 ] Annoying edit lock message Message-ID: Feature Requests item #916149, was opened at 2004-03-14 21:47 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=916149&group_id=8482 Category: None Group: None >Status: Closed Priority: 5 Submitted By: Simon Lieschke (slieschke) Assigned to: Nobody/Anonymous (nobody) Summary: Annoying edit lock message Initial Comment: I use Mozilla FireFox, and when my edit lock on a page expires, I get an annoying blinking "Your edit lock on XYZ has expired" message in the status bar, regardless which tab I am looking at. Could this message possibly be made less annoying somehow? ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-05 00:18 Message: Logged In: YES user_id=100649 It has a reason why it is annoying. ;) If it starts warning, you risk that somebody else also edits that page and you have to manually merge stuff he saves before you (if that happens, that is much more annoying). Even if you are working alone in your wiki, you should SAVE your work from time to time, or it all will be lost if your browser crashes. Either use "save" button or at least "preview" for doing that. After that, the edit lock period will start again. Another option is that you set edit locking time to a higher value, so it will hit you later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358482&aid=916149&group_id=8482 From noreply at sourceforge.net Sun Apr 4 15:58:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 15:58:05 2004 Subject: [Moin-devel] [ moin-Bugs-899133 ] UserPreferences: can create w/o pwd, but then can't login Message-ID: Bugs item #899133, was opened at 2004-02-17 23:16 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=899133&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Randy Gobbel (gobbel) Assigned to: Nobody/Anonymous (nobody) Summary: UserPreferences: can create w/o pwd, but then can't login Initial Comment: It's possible to create a user profile without a password, but once the user logs out or otherwise loses their cookie, the only way to get back in to that user profile is to have account info emailed. If the option to email account info is disabled, the user is screwed. Allowing the creation of a profile that can never be used again is a bug. Either passwords should be required when profiles are created, or login without passwords should be allowed. Ideally, this would be a site option. ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-05 00:57 Message: Logged In: YES user_id=100649 fixed in tla moin--main--1.2 branch In 1.2.2, a password will be required for new accounts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=899133&group_id=8482 From noreply at sourceforge.net Sun Apr 4 16:00:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 16:00:02 2004 Subject: [Moin-devel] [ moin-Patches-686959 ] Alternative URL / description separator Message-ID: Patches item #686959, was opened at 2003-02-15 07:15 Message generated for change (Settings changed) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=686959&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Later Priority: 5 Submitted By: Elijah Cornell (ecornell) Assigned to: Nobody/Anonymous (nobody) Summary: Alternative URL / description separator Initial Comment: wiki.py _url_bracket_repl The change will allow for the alternative use of a double pipe '||' to split the URL and description. This will allow for URLs with spaces to be used without having to manually convert the spaces to %20s. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-03-27 16:06 Message: Logged In: YES user_id=100649 Please see http://moinmoin.wikiwikiweb.de/LinkPattern for a discussion of how a better link pattern should look like. If we get to a good and complete new link pattern there, this is much more likely to get implemented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=686959&group_id=8482 From noreply at sourceforge.net Sun Apr 4 16:09:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 4 16:09:01 2004 Subject: [Moin-devel] [ moin-Patches-917681 ] Python 2.2 mail:Header Import Message-ID: Patches item #917681, was opened at 2004-03-17 00:01 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=917681&group_id=8482 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Robert Bushman (rbb36) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.2 mail:Header Import Initial Comment: Hi, I haven't done an exhaustive search of your fixed bugs, so I apologize if this is a dupe. I just installed 1.2.1, and like the new features - particularly logging in with a wiki name instead of a user number. One small bug I found - Python 2.2 (at least Debian Testing's version) does not have mail:Header. The following is the diff for a simple fix: moin/lib/python2.2/site-packages/MoinMoin/util$ diff mail.py~ mail.py 36c36 < from email.Header import Header --- > # from email.Header import Header 51c51 < msg['Subject'] = Header(subject, config.charset) --- > msg['Subject'] = subject # Header(subject, config.charset) Gotta love Free Software written in Python, it told me the problem and I only had about 5 minutes of downtime! Keep up the great work! Bob ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-05 01:08 Message: Logged In: YES user_id=100649 A similar fix will be included in 1.2.2. ---------------------------------------------------------------------- Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-03-27 14:00 Message: Logged In: YES user_id=100649 This is not a bug, your python is just too old. Minimum requirement is documented in CHANGES file. But your solution is maybe helpful for other people having to live with a too old python. Thanks for posting it! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=917681&group_id=8482 From noreply at sourceforge.net Mon Apr 5 14:25:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 5 14:25:03 2004 Subject: [Moin-devel] [ moin-Bugs-930036 ] RSS feed dies with comments Message-ID: Bugs item #930036, was opened at 2004-04-05 21:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kaye (mayhemchaos) Assigned to: Nobody/Anonymous (nobody) Summary: RSS feed dies with comments Initial Comment: The RSS feed feature dies whenever it attempts to process a change that has a comment filled out. This is moin moin 1.2 and 1.2.1: Python Python 2.3.3: /usr/bin/python Linux grunt 2.4.24 #2 Thu Jan 15 14:08:29 PST 2004 i686 MoinMoin Release 1.2.1 [Revision 1.184] Mon Apr 5 14:08:32 2004 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 From R.Bauer at fz-juelich.de Wed Apr 7 20:52:01 2004 From: R.Bauer at fz-juelich.de (Reimar Bauer) Date: Wed Apr 7 20:52:01 2004 Subject: [Moin-devel] where to search Message-ID: <200404080603.01685.R.Bauer@fz-juelich.de> Hi all Iam interested in a where to search function. We have the following situation one master wiki and several child wikis. It would be fine if the search function could be configured "where to search". This means on one site searching should search on different others This means I would like to have in moin_config.py a parameter, e.g. WhereToSearch = [self, moinmoin, linuxwiki] The list should corrospont to the interwiki list so only the interwiki names must be added. The result should be something like self?action=fullsearch&value=HilfeZuAktionen -------- http://linuxwiki.org?action=fullsearch&value=HilfeZuAktionen -------- http://moinmoin.wikiwikiweb.de/?action=fullsearch&value=HilfeZuAktionen -------- Reimar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From fcs at modcult.org Sat Apr 10 12:09:10 2004 From: fcs at modcult.org (Finn Smith) Date: Sat Apr 10 12:09:10 2004 Subject: [Moin-devel] Macros and Caching Message-ID: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> Hello all, I have recently hacked up a quick login/logout macro for MoinMoin 1.2.1 based on the code in userform.py and the corresponding macro and action in wikimacro.py and wikiaction.py. My macro, called UserLogin, is a simplified version of UserPreferences. It does the same login/logout action that UserPreferences does, but removes all of the preferences changing and saving code. If you're logged in it simply displays a "Logout" button and if you're not logged in it displays "Name" and "Password" fields and a "Login" button. It's meant to be a small and clean alternative to having to go to the UserPreferences page to login. The macro is now working fine, but I have a few questions. First question: Currently, MoinMoin caches the output of the macro when I need it to execute the macro every time (or at least every time its action is executed). If you login, it sometimes still displays the fields to login, and if you logout, it sometimes still displays the logout button. Hitting "Refresh Cache" at the bottom of the page always refreshes to the correct output of the macro. Is there anyway that I can either (a) force the page the macro is on to never be cached? (b) force at least the output of the macro to never be cached or, the preferred option, (c) force the page to refresh its cache whenever the action corresponding to my macro is executed? (i.e. the output really only needs to be refreshed when the login/logout status of the user changes) Second question: Is it possible to embed macros in the page output as controlled by the page_header1, page_header2, page_footer1, and page_footer2 variables? Currently I think the answer to this is "no" from trying to do it and getting no result. I haven't looked closely enough at the Parser/Page/Formatter code to see exactly how the pages are being built to know for sure. Last question: Currently I have three files for my macro, based on the way the UserPreferences macro is set up: MoinMoin/macro/UserLogin.py (displays the form), MoinMoin/action/UserLogin.py (performs the login/logout logic) and MoinMoin/userlogin.py (contains all the actual code and is loaded and executed by the other two). Can anyone give feedback as to whether this is the "right" way to organize my code? Is there any way to encapsulate this all in one file in one place? Thanks, Finn From toh at fuji-climb.org Sun Apr 11 07:07:02 2004 From: toh at fuji-climb.org (Fujio Nobori) Date: Sun Apr 11 07:07:02 2004 Subject: [Moin-devel] Macros and Caching In-Reply-To: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> References: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> Message-ID: <20040411140315.GA9215@motsu.localdomain> Hello, I think I can give you the answer for the first question of yours. On Sat, Apr 10, 2004 at 03:08:55PM -0400, Finn Smith wrote: ----snip > First question: Currently, MoinMoin caches the output of the macro when > I need it to execute the macro every time (or at least every time its > action is executed). If you login, it sometimes still displays the > fields to login, and if you logout, it sometimes still displays the > logout button. Hitting "Refresh Cache" at the bottom of the page always > refreshes to the correct output of the macro. Is there anyway that I > can either > (a) force the page the macro is on to never be cached? > (b) force at least the output of the macro to never be cached > or, the preferred option, > (c) force the page to refresh its cache whenever the action > corresponding to my macro is executed? (i.e. the output really only > needs to be refreshed when the login/logout status of the user changes) I think you already notice that you can enable/disable the caching in your moin_config.py by adding the line: caching_formats = ["text_html"] # for enabling, default in config.py caching_formats = [] # for disabling This fact is almost the answer. If you remove "text_html" from caching_formats in your macro, moin doesn't use caching. For example: # first disable caching if enabled caching_flag = False if "text_html" in config.caching_formats: caching_flag = True config.caching_formats.remove("text_html") ##### your code here ##### blah, blah, blah, # enable caching if necessary if caching_flag: config.caching_formats.append("text_html") I am not sure you are reading moin-user list, but I am the one who send a patch about Include macro a couple of days ago and complained about caching didn't go well with this macro. Now I got the solution and I am sharing this with you. Hope this helps. -- Fujio Nobori il|li email: toh at fuji-climb.org q|@.@|p m. ( o ) .m ~~~~~~~~~~~~~ From fcs at modcult.org Sun Apr 11 22:09:02 2004 From: fcs at modcult.org (Finn Smith) Date: Sun Apr 11 22:09:02 2004 Subject: [Moin-devel] Macros and Caching In-Reply-To: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> References: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> Message-ID: <75A9ECF0-8C3F-11D8-804E-000A9575E412@modcult.org> On Apr 10, 2004, at 3:08 PM, Finn Smith wrote: > > First question: Currently, MoinMoin caches the output of the macro > when I need it to execute the macro every time (or at least every time > its action is executed). If you login, it sometimes still displays the > fields to login, and if you logout, it sometimes still displays the > logout button. Hitting "Refresh Cache" at the bottom of the page > always refreshes to the correct output of the macro. Is there anyway > that I can either > (a) force the page the macro is on to never be cached? > (b) force at least the output of the macro to never be cached > or, the preferred option, > (c) force the page to refresh its cache whenever the action > corresponding to my macro is executed? (i.e. the output really only > needs to be refreshed when the login/logout status of the user > changes) I found this line and comment in macro/FootNote.py Dependencies = ["time"] # footnote macro cannot be cached I put this line into my macro and got the desired behavior. Problem solved (I think). I still don't understand what the Dependencies variable does. I'll have to go over the code more closely to figure out why this stops the caching behavior. Any quick explanations are welcome. -F From toh at fuji-climb.org Sun Apr 11 23:03:02 2004 From: toh at fuji-climb.org (Fujio Nobori) Date: Sun Apr 11 23:03:02 2004 Subject: [Moin-devel] Macros and Caching In-Reply-To: <75A9ECF0-8C3F-11D8-804E-000A9575E412@modcult.org> References: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> <75A9ECF0-8C3F-11D8-804E-000A9575E412@modcult.org> Message-ID: <20040412060144.GA23063@deshi.net.sony.co.jp> Hello, On Mon, Apr 12, 2004 at 01:08:39AM -0400, Finn Smith wrote: ----snip > I found this line and comment in macro/FootNote.py > > Dependencies = ["time"] # footnote macro cannot be cached > > I put this line into my macro and got the desired behavior. Problem > solved (I think). ----snip I put "time" into Dependencies in Include.py to which I applied my patch (see my patch in moin-user list), but this doesn't fix the caching issue. What does this "Dependencies" do? -- Fujio Nobori il|li email: toh at fuji-climb.org q|@.@|p m. ( o ) .m ~~~~~~~~~~~~~ From festifn at rupert.informatik.uni-stuttgart.de Tue Apr 13 01:59:03 2004 From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi) Date: Tue Apr 13 01:59:03 2004 Subject: [Moin-devel] Macros and Caching In-Reply-To: <83093054-8B22-11D8-8DF6-000A9575E412@modcult.org> Message-ID: > The macro is now working fine, but I have a few questions. > > First question: Currently, MoinMoin caches the output of the macro when > I need it to execute the macro every time (or at least every time its > action is executed). If you login, it sometimes still displays the > fields to login, and if you logout, it sometimes still displays the > logout button. Hitting "Refresh Cache" at the bottom of the page always > refreshes to the correct output of the macro. Is there anyway that I > can either > (b) force at least the output of the macro to never be cached > or, the preferred option, As already stated the Dependencies variable can tell what the macro depends on. This allows MoinMoin to deside if it has to be executed or not. "time" simply means it has to be executed every time. MoinMoin is supposed to use ["time"] as default if Dependencies is not given within the macro. If that doesn't work (I did not yet verify) this is a bug. > (c) force the page to refresh its cache whenever the action > corresponding to my macro is executed? (i.e. the output really only > needs to be refreshed when the login/logout status of the user changes) You can clear the cache manually within your action. See MoinMoin/cache.py for the caching facility and MoinMoin/Page.py for the key of the cache file. Nevertheless you need to know which page your macro is on. (searching is very expensive) > Second question: Is it possible to embed macros in the page output as > controlled by the page_header1, page_header2, page_footer1, and > page_footer2 variables? Currently I think the answer to this is "no" > from trying to do it and getting no result. I haven't looked closely > enough at the Parser/Page/Formatter code to see exactly how the pages > are being built to know for sure. All those page_* variable contain pur HTML. You can try to use Macros within a theme but you will need to instanciate a lot of the MoinMoin maschinery to do so. Probably it is easier to call the macro function directly if this is possible > Last question: Currently I have three files for my macro, based on the > way the UserPreferences macro is set up: MoinMoin/macro/UserLogin.py > (displays the form), MoinMoin/action/UserLogin.py (performs the > login/logout logic) and MoinMoin/userlogin.py (contains all the actual > code and is loaded and executed by the other two). Can anyone give > feedback as to whether this is the "right" way to organize my code? Is > there any way to encapsulate this all in one file in one place? For me this look good. You cannot avoid haveing at least the action and the macro file. YOu could move the content of MoinMoin/userlogin.py into one of both and import this file from the other (via "from MoinMoin.action.userlogin import myfunction" in 1.1 and wikiutil.importPlugin in 1.2). This has pros and cons: * no file in MoinMoin -> can go into data/plugins * not that nice * not compatible between 1.1 and 1.2 cu FlorianFesti From R.Bauer at fz-juelich.de Tue Apr 13 09:46:03 2004 From: R.Bauer at fz-juelich.de (Reimar Bauer) Date: Tue Apr 13 09:46:03 2004 Subject: [Moin-devel] My event.log confusement Message-ID: <200404131857.47062.R.Bauer@fz-juelich.de> Hi, how could I control the syntax is used to write the event.log file? The server wiki writes: 078499037.2 VIEWPAGE http_referer=http%3A// The standalone wiki writes: 1081873974.19 VIEWPAGE pagename=StartSeite Reimar -- Forschungszentrum Juelich email: R.Bauer at fz-juelich.de http://www.fz-juelich.de/icg/icg-i/ ================================================================== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From mike at nospam.com Tue Apr 13 10:31:07 2004 From: mike at nospam.com (Mike Rovner) Date: Tue Apr 13 10:31:07 2004 Subject: [Moin-devel] Russian translation added Message-ID: Hi, I just added Russian language translation (ru) to MoinDev/Translation. As I don't know (README says nothing) where to put ru.po (utf-8) and SF is in read-only mode I attach it here. Please correct me if that is not appropriate. Regards, Mike begin 666 ru.zip M4$L#!!0````(`!&/C#")B83A,S@```_(```%````:_IY? M<8!E;,^ZV_<+QC at AD%%8A02!,Q<1A*J[CMTUKJ[JJ:JV<90/7)9K6>*/1C ;H[JHZYSWO]7DOE3/BJN]X M^$=$@>6%KA4YOB?>.?/.&7'5V9#BNK_IR4 LMP/Z\%[+C]J6X]:;?GME7$Q/ M3L["O>UPW;'%Z=/X(8P"_'3Z6N#_63:CVA6[]GL9A+#J4KK75'WZ,P]NNBX[ M?A#5KN+SM?>[ZV%MU5\2=.G:)ZNU2X$D>FJ7K4 at NT6ZUR>G:U**8GEZ:6_CW MR:G)275S[;K<=,+\O;.UJ2DQ-;E^Y[KA%%8#_UNT)1K?K NZYZ,^.FK M5ZY^D+)BJLZD7/*]2'I S78'J([DG6BBXUJ.=UXT6U80RNA"-UJK+6;O1#.X-[L7[<3]^ MC9??.;,DKL&U>F=[:6INYITSXZ*S';6 E7""MA4EXAUU at 6U"VDXD;7%V-'+: M6'6"SA:RP/%ML.:XK/#\2#;CJ-=VN M#1= T6&]4%I!LR4"&7;=*#R5DAO_!-0^) 8Q<4=Q;_ 4^!+O#N[",?KP!21U M7]W1'WPY>"1(>/?AQKOPR$'<@P,*?!P?.XY?P[EW!_>1MW3#WN!!?#!X3 _< MAZ>10227_;AW*LN$N=G92J8KK156B'PX.VK#N<="XR3/#)+A4/>->S)[S%7O M<1T4`Q47^+86^&UF]&>GSX[BA['P,\.[Q,]Q.SA>+][!?TF=CX$!/=(Q_%)D M7':I#%7SDY54K6J9!XJ^4$3^4.+^#[F=VQ_E]*9(-$B'I 6"'T;?XE0E?:!? MRYV5Y;!MN>[*E36Q[7=%V&VTG8C5%>\>AX]2_8KLW;3=\\>^;-W\'ZXTF!_6L-AUV[-:MY0EX;'D"C44MHY:E/=I6,_!%$TY87Y[@ MDRY/=.B:$6]2-L3/@;]]TD/M?_;!0 at 9_A1_ 1L3@/^':W?@0#0*5YE#$+T 4 M.V!;]]E$P#S ;8#P\!9SG8/!4Q A/(D6MT<6^Q4[EL%3YE_\+=XDV/O!4F!^ M<&.BG633972@"J!B`!VOX*Z'!06"G^*7;/OP+YHTVCP00HL+\'&]>!\>.%[Z M5PBF( E38>*V at ZK:3<#3'RMR*,WK%BVXD`P\@'$"C[7'R*[XG.99*=#*R#:XGDN&2L==W M$-;Z.?L!JWC-&G\,5/3C(XKK^.V%4H8O\:A+.4KFACI.\'1-/C)XS4#X6UY* MT+BP;(CL+(PM)VK!9[0+`4LT6P"YR*<&0<\-JY'IW$X6N$V7T(KJ&2^E MO /%*V)HXA/N4?S>!>,_SAZK-V[>S5S("T"!@)YR-'UF%<&?-[GUX.:WTIOE MX;DT%DJ("&BK>'Z*!LR:T&D[KA40 at T*P9F"JO2WD'<#"];IIPS_'OS#U#P;? M4 2\#Q[LP> )N-TBT+E'Q \>`O6_ at +0/22D4E.OA5UH[H?4#@I5L9.> K V' M/1 %T(7\+_-3,V]Q1 A3W^:(E&X^%4S5X.D)_8U!Z]Q4[I>%Z=F$,KR 4--I MM[N1U7"EB1W_!CMJ:,M!B=!C/FR<*M]6`]Y+EH2SB??@__'8$@1I\$H17#+Z'Y>=:6*ST-7B7R$?7'/D,4GHEMY7LM5 at -6*^A M`"&&@H\=LN/_(%@@['FR_>8K]_L3ND[2'A(E@,6SH_CI-BX*65X+<@9YIP/0 MV?Y5$L-\+;- at 5G[ELEBL#K-OHY=0,1.,^=L9T7:\+ at 2$^C^5> 2-Z/2^4CG! M'FR$+ at U4#3!HN:M8K%:P__>A0 at EV9/\+#@5^`B0%X?LHWBD]UG3J[V[X;8GP M0+H`#6SI2DQ64DBTU0(42;YB2\(YE$,PE>I[M. :_B4417=+0J7"]P2>59!, MG"@8>:E"3:<@*4-DLV5YZ[^>2(.SP/5_$JDSA5BW4)UT`P[('"BT-D]R'*ZY MN=(*I5#^!N$0/8+5$%P&?_'JXK)/D57]DJP+3@&4U0EYI0_QH at 6ZZV\(*Z*E M;&=M3=4:X)/K>!MCE'B'$HF"F]"O-*3T$AGD8);)Y23Q?D.8LO=K.,V9W7." M(K `P5%*Q0A;I3D`H1M"S,]3]D,!FH/!+O"T^8OIZ7&B+ MC\IW!2C0UD6M;I/M!C!,Z'QN)E4_*Q5[3+D:04?>[9 \%VDD"I*4%\$_X@\S MJ0-1E^Z_J"'6C0VG0_4JMM*2$AIJ6I^0SF&""SP:V7,9\-2$YB9TA+^I(-^UG(!F+;;R *K`?B571V[I at SL0@>R MR\9-%0O"EX=*$0SIZDPB:YDJ`)?2-*TQ_?+'/J:O#E*VDFZ_C+X&*UP[Y+32 MLGP_?KU2OF2UI5^U-DR'WI"NCTDQUNDBN>X'V!5(/F9*Q=_JS?O#TB4L8:/_ M(ZCWBNID_<&3W*(E),_HQ.Y22P(6NM&1+OC ]1S240Y4T:#+>\4;S M^0;&K4LD9/.$9EE?K5\(!>4KIZ48RVM*UU1+X(-*?4L?G9T>%N/?WQ8M)Z+\ MR3 GH/YVHQM%OG<;^TYC86I:&/$[H,94&&$U#@6X1QE at 1P,#-$! IRF]4-[F M",/%3U6!MGUO)!);EH>&8$$V![L;.S?I=%5[@P[!2GQ/AH!N^1^#K7K*3>R>5UUNB[;/F+' M`+9!!09("O&C8T%8)40AK69+P)5,N9+!/R,<,7B(S"&\=DP5<^U\7\18O7BD MBHG[))$=$WF@?^Z7$IC&6"RVV]'*!^T.8%(G7%J>L%7'=]FV5T9&EF5[Q8DL MT!J0(WP>&3DO1N!G)=*&[Z8Q;41=3"_CTW at +BMQJAK\#_=I^8'S.0`YB&I!UY5U.)&=G"A:^5!:V'/.'_2"6'4B2!:F MQ(7SXD+R;1H^XM?D^PQ^3JF]D%Z9I2]TK_YMCK_E"/@(>^RYW5DA\%"JP/Q; MT>BZD$*&Y\54?5Q8\.WD:?K/WS'NV1UB-.?2_L/?F #13<_.]T(K.8& MD$@A&KQ52=)+"Q!-%2P/Z*R(E91C]CW4 &%O-7KG*#C M_\;\!RX<$((!YU2PPOAG!6\@=]7&F/DQM^U2*\9J&:<-<9(2H3C0>ZN-P7_GC#OFEBT')&.! MWN!+ at A 0NL'8:5.4R+[N+2:T[C!>H+8P18D'\9L3. (EN0."F1B:?U(R[-$G M1 $@?7(-Q##<;Y^P"&[)LQU''+LP3D$8 at U/ #<.]!1WN/CZ1=QGQWV&5%[0S M9%E%UT&X>Q\/**C2RLOTV9%4720^(D^>0 M*2BRZ.Q[.86G7G>FZ\"1737G4SBOHWMZ\&(8GYW681Q_!,@*61L!,#=34HJ_ M*]1 4_S%A8AZZ?KSU95H./QE:07B#\Z&@ZW18)P80G]A4ZJ%V478;7"N2DTI MBTI[G'&!TZ4O.M_R/2KFA^"LDV(^=4Y at .0;0&9!63S^A#JQ9/AN->V,G8UB)S at SI)"EI);4& M$#GF8DJ\CMY'7:^0R_>Q67+HT;%?4PFH.+$'7(P/JYXJJ\Z_*1/"$M,>YU$O=UTT`'(@H3,/CD at 6;.'8@:0PF3CJ0Q1+A>&DUE%0F M\=:H3N76>LZD'>D"C C.(.3:X"F3D?&/YB[LYK*UP?CX5 6+SE6755:3VO=: MUZ,*/C OZ@:>M+G5+H,`3+KIVYB!!\VQ0AOT&,NC<8\$3&IZ5T<<92M<^#BB M^-ICM[R#WNQK. ;''+UR&>W5HYDW3:.Y)3[MX,#)\$9D[I'8**8K(SI)?W(N M+<>AXS1G,=GE85-Y+9WR4/4$DW7/,'"I7#WC8\"+/*%H3Z-B5!@LYMCH:DK9 M-9<6Y6Y$5M0E"P at A:T9/:[ICRJ(S8S _)2DK!M,TXJ0#;?WR?/KU4BDA,]6C M," $%QB"`@#)RZ;3<3"[`;<%WT,BVZS at E2^OJPD?^PW?WLX%+ETH',?, at BH& MP(7(-/2?RVH#RJH2?$#SG>-LT%0XK1BKF!\R9W7FC)KN15&0(\JKF#$J63+J M^E-VOJ+X-/FIAP3]RR>PRBA>F-9%E1,-I.1TMS"0DO'DPP=32A5W87K!I*?) M4R+4Q9/M3K3-XS\Y1YUNG[:X>@DB>\#NER!VEH!2$2[,3!I![X8?!-OC(BSK M5=Y;<,E->XI&X&\A*J,,'4%4 M-_I-QPHC2:MF*J-4B(JHE2# @WMBW4?HM64%)#J\P,LT70. MTFBV<'A)WH'X&=(`H BZMCRETN["_"Y!;/3[1UP2)3,_%M3T&M+)K>H>E#1T MZO#.CV,3 M%YGS!.\#TQ7T/&V:)TUZ/1U*,AC:,A68`L0TSX4A1 VYD&2,Q)8S$CK5 M?M*(5_TXFF;IJXXZ5H'N5THI&>BF)(@*.RJ1Q?B%@NOI)A]WM5\HF/HX:R<):,;WZ]S&WQ)YF MX4_QM"K1IW'-'=*;>_#0D-WB/9([**C:L^R,LV80LN$#NC>5[FC/KSS;N!XT MR4R:/>/<<=>TY at -6_3[+==B9:OGDL:X>.FC MD-.XI),:.I!Q\$@D1EL/6[EM!_(`9[T5T;U.="KK.?41R7YT at UG91K;#V1.9 M5*@W"A2,":WJ3\%OBW^%"Y;GZZ3]I,A%2P1>.+5> $SX!B MM2+3\!,TV&9%*%Z,4! ,;1DA>@1N61U\`\O!5[!,C<6:8X^2PQ=JV$:K;H69 MENK>XI 7X506SK-V.*,$287$5]KT_"K\!C(+;UOK_IBM1 at A'PS$(^#X#`3U2 M!6NM!Y87*2A#:V9>!:AG95TVII<2$)]HZ#5+7:SG#D<'C\8X)%#($DD[$_?E MZLT#2G;)?-X4"'E2OGV\6Z5;%6GXXI#7_X"43PAH8,$L?8>)NF3(.VF3WU2M M09MGAE/CZH(>N7#\1A= ++YZ".OE^\I5[V_1*T)4C: 0A"'W&[CV#9VRQ]L2 M/"@PX+7Q9D],<^SEM;"G?!&'Q*C>HJDLGT)9G!^JHE5\`E3J)6PJ\"-DP+>M M,0$)<-HY&/R@$VU MZ2L@'Q*S0Z^8OI5O.EE-\'\R-:U2`$RW[D38W$YLDBJC,G#\C*_Y6UR)_XP1 M:]6S5U7I'1,?O"0>J+*AH,(WM9P58H%/Y2<8/M*9OK2(0TB<.0#\1OYG;,08 MJZ?Z;N)%E%; 2O1^;AA9[[=9RC_$;5Z/(GR/K KD7%^ CO;JL1O&PAXIAPB"4A(#$J\/7]1N0JN<(Z:,5A@"F6H % M7,0#@*,04H0M3-"(18"V`D at J,PZ0F4,&#(L1D4 at 9[(]Y,:2A'B=O56)E+(S] MATT?CIN<2+^*4=?]3TWQJH]K\Q2P&G\!>M6AL>R-T<9WSW MW7?5V")JHK..3TS-:+A]V5E;,PMW/\:9MD#Q2=T*O.*M^5E$.4B*KKWB8S." M7E">^-C:=-:M9.I^:E[G+GBV7)6^C:2":CR+W$M:ZB5/I\7FDF>? MQVE+K?3I]&U7RQ@&6W[OS+^5L%E+YH]7/\K7ALW[=&7^6N!X&3;$NTD?OOB4 MGO[Z?7YJ6;V;77AD5I<+/_3;YK%QWA33HM?%1[2J?-K)!77N,#WD1P+YER[X M!WQFYIPA(%)(]:)SKA#ZANP*4B_2_5U!((?+2HB8=PL+STZ9;^3A\*0?;% F M`;<$V]GE.<][14X1S)&@%UGT_:0R0U!C<(^W2:QI:E+SZ!.(3\E4.N =-7]$ MUQ4,BN$ MMOSZ\YGU45* QGVW805OW6&@)C:Y&T^A#;_F=UC([!#YG8F&#S"DS2+$]^-: M:L+Q[3MJZ2$\44YC(GY),7J/2IWY^95>XE52 at A8S!+$ZV;G@=3)UNEL6XM*- MM%>]:-L\ST?]!?T?`.&!$GJ+NQ W=SA#I8WQMEJLW\7.S-O$]&IV;N)%8X80H0>(-X%^8_4?I<^GN[G.VL]8]PDEC+ZS;B+`-6PD"^./]OKW6F[LD7T7'$4;P?>=9/\0D+5Y0'D MEX%TO]$'QD3YB'6LT1_@,TY55UR8#>!=J"-#S7J/S^M_H*__A:%VP1O**:47Y7TK*0/>/' P1">J]"VF'7 7(!,&O=)\EQ0 at QF;[/5 L M)/79J8D&/I at L3@4`!D&Z3-(M!I]UA#[H$BLJ'.EX=O3\X:L(06HU-O at S@7GT M`-2H*(RN%;AU]L--)"T.#"]O6+[$W"FD./*-9V86 at X^<=R%GNN77/^K#DDRA M<(I8/K%+L9=O.E[PEGMIA<^A#M>7N,6UR7I4>.E+4B-K^@JL:[RW!1<$X5'1 M+\T[6#YQ,1I8[R5>X#W(O(FML-R,[BR&#O 5.^T[%+E>R2ZT^\4`'@+F'_S[ MF'O.$5NW^8\=:A/MRDI6/H2_E%^1Y$/I^R!&M#N')_\NO/9(N;XUKV" GDH) MV2&[ADX>8.*;.9=FF:E(D*ZW!H9WM%L\"V8`F,=KL J,[?3,?[0'`0<>AYM0 M8+2&?QA24?1_3TKE-\Y]RQ]4Q:1$& &Y)[DG;.;VOE5/T2"-J<%$HF1CL/*#:&B1JH[-T8E MYC5!ZHGD%1 M.+2GP]X.@@X#\^\PNO"<6I at __+$7-=\#UCM47R.VGM>&D ML M]W.7V%@)EWY>[CE-^BEIMB*9![Y2Y$8V%]V=/Y=OM(8=;>ACR/P%?OGW2]+\ M/XQ,LN1T_W]XG7)OLB+'JL6 at B+5"HLD./".P.I7^1\9*N#[D94D6W@:67;>W; KFO,BRXP-<$>@88YJ ME7E7\46MG!HYA+ (.YZ,+>4.A!53,<$4/1 +\^%0R+8R7RL^`S!!RGB)6!"B MTK%QM=O9S79NV[1[,NQ9A*HW_[(,JE.JF39:08GNP**O?=BJ6/ )9A^9QB=\ M7T/&TJ=0MI:T(W(N7Y$F2A\ J M*V;/X9<-\]/8BR_Y+;^$08KV at +,:P2I:1XL1-G_(2ZJ]_]-(YSJYU$:H#U,1 M"4U522YW,-Y97WW\NC\]CA%/L` MT]P\H92W_=B4[DL#*G1&IHR8[RNORF7,43^(3.,%J#_B'494'O>4/T#?S;/( M[!X!Z8W.8XZ"N!:&RT^)R<".*=/9\-N!S15EZJ$6CC$-8\R8E%]P:J. MTI7ID?W]->IM5& WJM3@/:G8MB4F\ G=E!YX`W$_HJW,>5S/59^E[BJKBJP! M.<:$[;@-KJIV5PJ>\I&@&F^Y-_>?V'.IG9PT>:-T18X.D+$$9!DY!D[.L]'] M"$.86YH/7#]STXMQG-5Y7\AR)@Q/?%Q&(A$A7F+P`'R42< Y,F4,I>;#;_7Z MN5':.@! #M5K!'UMCL46P 8/C((+'B5CL7?S?+V3!RZ!N#F"A^5]<@&"16'A MBLB_0 at K*8[P-]_ OP>S5UUM(9TY>&+H*:2(=!,([)R="^&D&T:;PQ\@EC1*X MIJM2"1QU2_9C73+FZ37,G]]&&YT#B+#X*BZ+5#K)AV:S7U[9R)QA]7^QWH): M3[J (RL^C:T(;M=D81,6]!]C5ZN>=O.4+CV1IG()W;C03X604VZ\C;9AP. at W* /BL92I..'I:K KYASG%FN_ M/SDULQ%#[ON$K$W8*/73415[3R_=]$4>D5H]5XX7>.U 5'Z-WV6?0ECQRKSH MU6O6E"&=P[*WV,D((O=6RTH?AN92.C/NG"CKNY4/=J#*E2L@"C"%8+\)E6&B M)GN @@3?0>Z'>&N;P8<(^)B\-%'$Z4M_\X;#9IA8=X2%30[@;WK9R>@ZRPL4 M&X!P$FDRXH-7"QPK'YJ%%(NQ^"==3LN&&ZXXI\6N!@!P`J-SDL!>"\"F[PTW ME5?PD1*>F"_F`)6H;$/,0A1&*9OUVM_%S2Y()I<'3W6SK2VT?PTS\* RTK0P M[.>@).2I7PO30FV*!:HZY+/!J,;6#V^C8F9TE$1?Y61UOXL^)%;1__;(^WP@ M7)"_]YI].'7Z#EQK,4S;BCE(<9."_A*;UCM2WCQCSI#93]T=XU3A:HW:JJ*1 MDENC4&WA<+<_9)RKE56*3'RX1WJCFGHQ/EJ>'YUEKF(0S"<:+P!X M,"\80'W!"<7$`NG^#-=9JJSCF$!?YHK]XT\F?AIEQ7/S,^$3CP.^'62&>1Z1 M)LEKJQC)E\,)ZXN<-)7F#,$TBXNL"U_/U\Q78"P_EI0I[GD=5\1N%5PYR6H# MUO?:1%)!$7;'84040A57&.J^7XX?&Z%UR;D)KKQZ1LQ^4#J at MO 2IT$!0H/$D77F-VRSN8;COH5"#0]3$,?Q=;V^FN5G*B5(,7JSI. M"!F_FL<9SIF.>R/UT))K,/8[H+&_Y_$8R#H\ZK66`7]L4+QJ-!+4<<39F/:G!' M<( 78-V5,%/\M69D.3Y78V(=(T6I.*MAFX)5V6X^F,I6T0\$-?;]:R+DR,HW MM%?K0_P7"QN-RMB'?*-!S\_(DX590UA]:"LY.&6 FJ-@;HXK/:Y$JRB]"A1R MU%AP'R/!Q,?^UARZ at FKSS6&_7F18Q?7&A*DS M9JLPS&]WPFZISW2 =7D"B'6N*@/8A4^5X!Q"AW7'_ (NZ])G:QPS]2G^D9K3X0VVL?F$_1#> M5YL&4-'^^95KS(MD%6Z"U%"M6FPNB1,&O=RZCNC3`$MAZ)9'BN G+:B#M3TL MG at 6V+Z3A&)' ,$!P2+C=F42CK3K%X7 \%4DU==!PU\_A#UW8"`H)$G22;:<:4 M+UVM`&>+.J'MVT6/[HP9I+MHAQ! CC=JX,,A?O4V,4Y&6C M(+$INM1R\,"[!]Z0=4D/?00D,DW35]A?I(:D6;%;#'+JK"FW#KL&PN6%6_F< MF!?@<"6K`5+KG+];NPYHH<]''Z)M]Z"R5EG%_8BN)E)GH3.3/VEYZK,*%R.U_ R9]PZ5?+,ZBBO7+D.R>..2[,- MBLM-%-E-Y\)1W3>B$[I3/KD@/03K/<%SU7P=<:6]17HU[JK=6O M^1F'#EP>[-^T[FSR94D'^B%OJVH8I5]4K#N?>M_JLL=YX7&6%N*N&+0`P-?6 MMO3Z*(L/#"]#3%%.&A^;[X+*V^GK^[34V]WSGYFM%4!SV.99 K MK'M,^1B1^@XQ%&H/E&X-#!D"IE\U7*TH%61UF+.F*C._1.OCL&9:7J M_%RZM'6OX!Q%Z[*O^GO;/,XNM_I&Z/C%\"&=$?^!(M-XS0'KJ[. at 7IJ-,^]1 MYU2O>)!@.NTOOCF!!HCY-40K5/NF"08GQ+J3Y]FG:R'9U+4FZ-*U=O^.8]0T8;>NOZ)5M8"33KYSWB+KSMGW M)QO 2B14"\!"_E&T2HK7!\#FH]](;SU3,])0=X?E`?G&,="=H;I_G[TH!\3G MT%WU/CFQX"<6D9*C[OQ)TH?89[BORXY?AMYO:XKHN&8SK6UK^UHYTP M#T7 [XGU!\&7A(0XAPL0GWS9E\KC'\P+P=^*.JYFU=+HC+/3LXD_+"A'9"1> M1)MK.!CZ:Y-^Y[(:U/$A"1=KBXB"6O#'.H$FW!97\IW,BP;UK0^M?S_";6HG ME[B99[K9^TC`AIU[L?K;2&K M3ONL=0QIHLS%1!O<8UMQ21WL>KPV,1N$U=MI%T:8M ':_CH/[D&1>Y%U\HU! M=JO3`CZ.9?3]]F8;^D-:\9)9+#XSEQ$(8>-:#+ at X'D=<$,QR!"#P$2_B000V M"/KAAVC!@8GD1?]4YKK2N?F"2NHGSLI_$9;V$G-&]_:W:)9]9WW[!'QJAXJ\ M./+I/Q74LUJ,J;R(@/@]>N1I[H=(&BQZVA=QOJ/.# H0, )\DQ>+`^.K;DY+ M;$;-]4M;_N+THI(+>LD5Y413[3GWJ$P7^ K2 at 1#G_*OZ-ZZ=W0F RQO'XLF1$]60_ MAAQ9/$H$0KV[))SCDV-N.(%&_EC$+QVU\0 at LJK9]XQC;[HL*?@S:TS"B;W6+ MX?9VKP\.$A:]-,>*SHO_',6!J]Q"0;1?<=G!@X EKKC<^#AMRVG:SLBC0#EL MB?XR,2T-MBO>529NG<^-0P at 8M(-6WQQ4,&<;`(-C+AO*>VWJ3@;X&U-UQ)*A M+.:UTLM*LW!NEN$Q2[KN(,S5%,^ ]O5#7A/[2TPTR-^_3GY_S"> ,H! Z?G; M7QSD;OFDI():ORI,SF&$`,? (3-$-V1^>B&5&#J;]BCJ?1+T.5BHXWE%R 0? M82O(6FIG?X##YEBDU"WN4Q,MP XIT4:/.6T;QS#$&/$]SPN-3(?BRBG-3\B[ M6E*#'ZR=):7':VNG14K<-Z+;AT^]',.U4;NC-7W[//DK)RC"79QRYON_$2WW&2I2B66?8DB7D*'4FM(*CMMR/;P2V M,6P5;-%1ZI_RR;K MN"@D`D/!<$,K\@_E`:<#V,]71YBW%*[G+;^B/^D_5Z>&2H8/QSS@/Z];V/$W M>J[?T,]=-X4S\:ZR70=YO at 6!'N)YPI=IJY*OSTJ?[ZMM/&9OV(OA`-A?_*LK M at E0-<$VZV94>U\-N014P?[-(8:#:0.LO=;].+IQFJ^?OF@&=7>S?O64QY9!K M^#*%6)FB+\Q%] NX#VCN0T9>-1VZW!N;UKET-.SRL#-H;W>8T-QIH<74U%10 M3O$9ZB3?D$-;%1%[,MRH%"D^`>R??3,V8$7N5QCCZ'+7`LXL`6XF1*HIU-9QLH^MKXI)4??UH209JX'1ODVZ2JO"/^?)&%41=\?$?:U?+B1JB M?3K&L22G?)7_#\D9=V^.(47UV\^E[:DS7!$-YA'L![XOL[6BR?"<+)@P]T'7S.+4D)=IQPW1HZMBBO>Y8*N)6M_-.Y^SM?.T. M\M6%M&'8:&-6, (--#K QPAG;#V3?:H5\(!.X*T?E:9I,BWHA;[!;6!Z`T\A_EM1335TP%%==P]SLC&^+U+9 M3V(O)D\'Y8!R'_J*6'_L_ at Y\GXX0H(4H4MP4.+>BB%'U="S<]>U M!H#O-7B>VVU#G&^[/^(H0GL$\)"XP(I-":/D)IN8;=\H?+_ at CH4$B:[ D,#2 M05 at U+-*+0$[82CS"51I1Y/90N&S0>5?=\Q,U)#1GE"??]MXS?_7TN/20FC(\ MI3N]9#T3^-F#F*BLUMR%T-:'L9([?@.L_$?BTXH'`A5=,C\T_R@&:4"=YUP$ MY3(H$&K+IH+ at 3E?!5,CSQ54#*"O2A%SL4AU9FVL,6OW-(7EFHZ9#I$++?$ZX M*-^,[MNB=Z]GVEF5>*B0-].>87>D-T+P@]N$W3Q.+=+EO MBK*@$F=91 M"MWV!<]]+3!:A;X!<0HM)E 87RDY<8;@NX"EU9'A13)D/TK^FQ[B>R>80YA# M?I:\`"@RO]=;53/;DN,5JX-67Z,D->"6+%WW,C/WM8OAKT!QTKJ_ J_ at I^AI2J=G5/58_1[RQE!V at 2_%6M7 M//,UT2R*8.FL2NWBEG3($/:S1 9E=7@=:6D&>HY#R('O/PR3E'\N1>Y2)7]2 MQ3;J:5E*ZX03C=N]8=^>HM-KF_1_[8V1?F9^^WH??WC\@7] M/^GY<*9KR6EZ0*%&MY?=ZO7N8(^;(A\HY9./)TPHD"LGZ^>N0?%H^,:(9BG0 MCR8J,%OBBU-?,_I-[8HB,0(@/0!HV;V32\J/&"^TE.CAY-X2U F"3< RZ/J# M5A.X\IV(X84M48*4[XG#23)8[:Q?TP ?4?RK#/%$/CB17K>9UCJ@ M/,0O&U%];(G(H8^]5=>.:3ZK6*1W!OI5X\YY]-W>3A/2@?VQL<0QI0>[.Y#*[A ,Z/!GH*WL96R%XSN-AKYLT-MEG^86#PHQ^N7 MQ;S7:$M%WL=*%/P:-?FSC//>S7=<.A'X)CU[UT4HJ"R3)F\===6?1TE(^]Y9 M/'95HDH=%3)B_.08-,PO51XMU!15B<3>3$XO*/%P7;$"??A2> K,"X0$=4-*EY at M(F-YF-6 83QJBO,7)\?5,7 M?:R;FN;L5KX!F(A'4TT)\-97[<8[G]2W8Q&Z7'E4$VI,T6ZLR_ at 7&(=P.SB^ M[7&RZTZGKQ];ZW6,#4E59,@^>TO5R_= M8!1QQK-7H5G\,_KZK4//T'$B.J?OR("#?+(6*HF(>HB.!L->?X*0H)8W at 1Y^2'$*X` M6\3^UG%P$*8B834&G/MQ17[&]L>)]"@&6!W",0KT?^& %E=?&-9GSA^\BF29 MX6_9D1'^/$F%++K:[.=Y]S7(<,24[GZ^_IJN*X$$K.]1N]TG3]1K%I[,)38: M.<:%0".,*MK?8822O446>N%IFBZ?LKNN<241UM_JB=&13M?\"2 at EMQ6BFN A M]E2Q"R^@1IX8#[^.H12 ILR,"DKX+3K*_V=\Y9?$2.U&@7M'5G_^NA+'3J[L MO at XZ:N QXT#=0E_73PFN+PYF\Y0_;MWDT0LJ0TEA[J+ MA=C>8#6AY&FRY*KZ1GJ02RS24$7?:,U_4[JBD]AXT2%3?BT@'3"V7CD#O\0$ M_6*L+QCT)<*0P14;C;?7Z))YW@(]>3,L90$7/B#&01SN ME1"D'O<6K[16%DO$VX+-_;#$5"@74/(UYV*KV6CW,4^0260')FAM+ at M:#3V9 M,7&+ENJ+\8 at WXI[5T4!Y/434`=ZJQ-QS/HD,C+(;YIV5F:*2_DK 9<+F;X;3>QBI]B#W?E2Q2,3-C9_\$2U>LUC:](4N.MR3`JY*D7$."#V<+$[C MY:(.$.9/YE_V+YE2-ER6X9YMAO\XN#JH<@1SVV%!B6VP$/TJ\7+S'FOGJKGT M?&TBVU;O\I=1)E;BG+E0*N']861>C%) I,*"@ADL01<+_`I_RAGF>KZ^8XTD)#5*' MC*WG# 5L,5> J+SZ3_HH( PC]G2!]L:VZ"[@#&ZK+O1[W4' >;Y$KGG?>MR" MH2)%1/@H%>,ZI*RAD8/""*;P/2'A[EX<%UVSQ*4OGP)B!,]0QY&'A738AVKV9_/RVAWPF!")S(A\G>I;3Y>(;_Z?Z/P@@V'DL('L2F:WF&L MI @PH(/Z`3>&V1NR-='#!AVU= Hello, I found that the raw text: {{{ 1. bullet item This line should be in one line. }}} is viewed: {{{ 1. bullet item This line should be in one line. }}} where it should be: {{{ 1. bullet item This line should be in one line. }}} Attached is the patch against tla (patch-280) to fix this issue. I would appreciate any comment. Thank you very much! -- Fujio Nobori il|li email: toh at fuji-climb.org q|@.@|p m. ( o ) .m ~~~~~~~~~~~~~ -------------- next part -------------- --- orig/MoinMoin/parser/wiki.py +++ mod/MoinMoin/parser/wiki.py @@ -510,6 +510,21 @@ # Close open paragraphs and list items if self._indent_level() != new_level: self._close_item(close) + else: + # don't want the raw text: + # 1. bullet item + # This line should + # be in one line. + # to be viewd: + # 1. bullet item + # This line should + # + # be in one line. + # of course, it should be: + # 1. bullet item + # This line should be in one line. + if not self.line_was_empty: + self.inhibit_p = 1 # Close lists while char-wise indent is greater than the current one while self._indent_level() > new_level: From noreply at sourceforge.net Thu Apr 15 13:13:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 13:13:11 2004 Subject: [Moin-devel] [ moin-Bugs-935700 ] Standalone server: fix file uploads Message-ID: Bugs item #935700, was opened at 2004-04-15 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935700&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Standalone server: fix file uploads Initial Comment: The standalone server doesn't set the content-type, which means that multipart/form-data doesn't work, which means that file uploads don't work, which means that creating attachments doesn't work. The attached patch sets content-type, and adds an inefficient .readline() method because the 'cgi' module needs it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935700&group_id=8482 From R.Bauer at fz-juelich.de Thu Apr 15 13:39:11 2004 From: R.Bauer at fz-juelich.de (Reimar Bauer) Date: Thu Apr 15 13:39:11 2004 Subject: [Moin-devel] Version included in macro names Message-ID: <200404152251.44354.R.Bauer@fz-juelich.de> Hi If we develope a makro should we add into the name the version of Moin where it was developed for? e.g. GANTT-1.2.1.py The one who like to use it could rename it after download. Reimar -- Forschungszentrum Juelich email: R.Bauer at fz-juelich.de http://www.fz-juelich.de/icg/icg-i/ ================================================================== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From noreply at sourceforge.net Thu Apr 15 13:39:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 13:39:20 2004 Subject: [Moin-devel] [ moin-Bugs-935683 ] Standalone server bug determining static files Message-ID: Bugs item #935683, was opened at 2004-04-15 11:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Standalone server bug determining static files Initial Comment: The standalone server looks at the filename extension to determine if a file should be delegated to the static server. However, it doesn't chop off the query string, so if you have a URL such as /PageName?action=attach&target=overview.gif, the extension is determined to be .gif and the static server tries to access PageName?action=... . See the attached patch for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 From noreply at sourceforge.net Thu Apr 15 16:15:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 16:15:09 2004 Subject: [Moin-devel] [ moin-Patches-935985 ] Add a global notification email. Message-ID: Patches item #935985, was opened at 2004-04-15 16:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon Oliver (gordocm) Assigned to: Nobody/Anonymous (nobody) Summary: Add a global notification email. Initial Comment: This is a very simple patch to add global notification for a wiki, this is especially helpful for small relatively private wikis where you want to see all changes (and not have to subscribe to every page). It adds three fields to the config, and uses them in PageEditor.py for the notify only. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 From noreply at sourceforge.net Thu Apr 15 16:27:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 16:27:02 2004 Subject: [Moin-devel] [ moin-Patches-935985 ] Add a global notification email. Message-ID: Patches item #935985, was opened at 2004-04-15 16:14 Message generated for change (Comment added) made by trout You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon Oliver (gordocm) Assigned to: Nobody/Anonymous (nobody) Summary: Add a global notification email. Initial Comment: This is a very simple patch to add global notification for a wiki, this is especially helpful for small relatively private wikis where you want to see all changes (and not have to subscribe to every page). It adds three fields to the config, and uses them in PageEditor.py for the notify only. ---------------------------------------------------------------------- Comment By: Nick Trout (trout) Date: 2004-04-15 16:26 Message: Logged In: YES user_id=51018 I may have misunderstood what this does but... subscription understands page regexs. So, to see all changes to the wiki, in user preferences you just add ".+" to your list of subscribed pages and you get all changes. ? Nick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 From noreply at sourceforge.net Thu Apr 15 20:25:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 15 20:25:28 2004 Subject: [Moin-devel] [ moin-Patches-935985 ] Add a global notification email. Message-ID: Patches item #935985, was opened at 2004-04-15 16:14 Message generated for change (Comment added) made by gordocm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gordon Oliver (gordocm) Assigned to: Nobody/Anonymous (nobody) Summary: Add a global notification email. Initial Comment: This is a very simple patch to add global notification for a wiki, this is especially helpful for small relatively private wikis where you want to see all changes (and not have to subscribe to every page). It adds three fields to the config, and uses them in PageEditor.py for the notify only. ---------------------------------------------------------------------- >Comment By: Gordon Oliver (gordocm) Date: 2004-04-15 20:24 Message: Logged In: YES user_id=341538 Yes, it is similar to that, but actually, we use it to send mail to an alias. Otherwise everyone has to subscribe globally... Note that the original patch suffered from a lack of testing, this new one does much better. ---------------------------------------------------------------------- Comment By: Nick Trout (trout) Date: 2004-04-15 16:26 Message: Logged In: YES user_id=51018 I may have misunderstood what this does but... subscription understands page regexs. So, to see all changes to the wiki, in user preferences you just add ".+" to your list of subscribed pages and you get all changes. ? Nick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=308482&aid=935985&group_id=8482 From fcs at modcult.org Fri Apr 16 07:50:04 2004 From: fcs at modcult.org (Finn Smith) Date: Fri Apr 16 07:50:04 2004 Subject: [Moin-devel] Macros and Caching In-Reply-To: References: Message-ID: <36EF3DD4-8FB5-11D8-A71D-000A9575E412@modcult.org> On Apr 13, 2004, at 4:58 AM, Florian Festi wrote: > > As already stated the Dependencies variable can tell what the macro > depends on. This allows MoinMoin to deside if it has to be executed or > not. "time" simply means it has to be executed every time. MoinMoin is > supposed to use ["time"] as default if Dependencies is not given within > the macro. If that doesn't work (I did not yet verify) this is a bug. It turns out this was my mistake. I copied the [[BR]] macro which has this line at the top: Dependencies = [] I should have just commented it out. Both this: # Dependencies = [] and this: Dependencies = ["time"] work fine for me. >> Last question: Currently I have three files for my macro, based on the >> way the UserPreferences macro is set up: MoinMoin/macro/UserLogin.py >> (displays the form), MoinMoin/action/UserLogin.py (performs the >> login/logout logic) and MoinMoin/userlogin.py (contains all the actual >> code and is loaded and executed by the other two). Can anyone give >> feedback as to whether this is the "right" way to organize my code? Is >> there any way to encapsulate this all in one file in one place? > > For me this look good. You cannot avoid haveing at least the action and > the macro file. YOu could move the content of MoinMoin/userlogin.py > into > one of both and import this file from the other (via "from > MoinMoin.action.userlogin import myfunction" in 1.1 and > wikiutil.importPlugin in 1.2). This has pros and cons: > > * no file in MoinMoin -> can go into data/plugins > * not that nice > * not compatible between 1.1 and 1.2 I ended up putting everything into macro/UserLoginForm.py and action/UserLogin.py. This has the advantage of separating the form generation code entirely from the actual logic of logging someone in or out, so that action can be used elsewhere. -F From R.Bauer at fz-juelich.de Fri Apr 16 11:43:04 2004 From: R.Bauer at fz-juelich.de (Reimar Bauer) Date: Fri Apr 16 11:43:04 2004 Subject: [Moin-devel] Re: [ moin-Bugs-935700 ] Standalone server: fix file uploads In-Reply-To: References: Message-ID: <200404162055.24590.R.Bauer@fz-juelich.de> >Initial Comment: >The standalone server doesn't set the content-type, >which means that multipart/form-data doesn't work, >which means >that file uploads don't work, which means that creating >attachments doesn't work. >The attached patch sets content-type, and adds >an inefficient .readline() method because the 'cgi' >module needs it. In addition if the attachment variable is set no cgi is needed. Is it possible to store with this patch data in a different path as htdocs? http://moinmaster.wikiwikiweb.de:8000/HelpOnInstalling/ ApacheOnUnix#head-354b04d9d28ce4a0e2160ccb1481ea3387856234 attachments ={ 'dir':'/home/jh/wiki/htdocs/'+sitename, 'url': url_prefix+'/'+sitename} Reimar -- Forschungszentrum Juelich email: R.Bauer at fz-juelich.de http://www.fz-juelich.de/icg/icg-i/ ================================================================== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature URL: From bernat at free.fr Tue Apr 20 06:25:07 2004 From: bernat at free.fr (Vincent Bernat) Date: Tue Apr 20 06:25:07 2004 Subject: [Moin-devel] Quirks in documentation Message-ID: Hi ! Is there already any tool to find pages that are out of sync for the translation ? -- panic("Unable to find empty mailbox for aha1542.\n"); 2.2.16 /usr/src/linux/drivers/scsi/aha1542.c -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From noreply at sourceforge.net Wed Apr 21 18:53:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 18:53:01 2004 Subject: [Moin-devel] [ moin-Bugs-930036 ] RSS feed dies with comments Message-ID: Bugs item #930036, was opened at 2004-04-05 17:24 Message generated for change (Comment added) made by msoulier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kaye (mayhemchaos) Assigned to: Nobody/Anonymous (nobody) Summary: RSS feed dies with comments Initial Comment: The RSS feed feature dies whenever it attempts to process a change that has a comment filled out. This is moin moin 1.2 and 1.2.1: Python Python 2.3.3: /usr/bin/python Linux grunt 2.4.24 #2 Thu Jan 15 14:08:29 PST 2004 i686 MoinMoin Release 1.2.1 [Revision 1.184] Mon Apr 5 14:08:32 2004 ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-21 21:52 Message: Logged In: YES user_id=470843 I'm not sure if it's when there's a comment, but mine is certainly dying. http://opag.ca/wiki/RecentChanges?action=rss_rc I'd love a fix for this. I prefer to track wiki changes via the rss feed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 From noreply at sourceforge.net Wed Apr 21 20:53:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 21 20:53:01 2004 Subject: [Moin-devel] [ moin-Bugs-930036 ] RSS feed dies with comments Message-ID: Bugs item #930036, was opened at 2004-04-06 06:24 Message generated for change (Comment added) made by fuji-climb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kaye (mayhemchaos) Assigned to: Nobody/Anonymous (nobody) Summary: RSS feed dies with comments Initial Comment: The RSS feed feature dies whenever it attempts to process a change that has a comment filled out. This is moin moin 1.2 and 1.2.1: Python Python 2.3.3: /usr/bin/python Linux grunt 2.4.24 #2 Thu Jan 15 14:08:29 PST 2004 i686 MoinMoin Release 1.2.1 [Revision 1.184] Mon Apr 5 14:08:32 2004 ---------------------------------------------------------------------- Comment By: fuji-climb (fuji-climb) Date: 2004-04-22 12:51 Message: Logged In: YES user_id=1014218 I sent a patch for this to the list, but got no response from anyone. This patch solved this issue, at least for me. --- orig/MoinMoin/wikixml/util.py +++ mod/MoinMoin/wikixml/util.py @@ -50,6 +50,32 @@ self.endPrefixMapping(prefix or None) saxutils.XMLGenerator.endDocument(self) + def startElementNS(self, name, qname, attrs): + # this code is a bit modified version of python2.3/xml/sax/saxutils.py + # i needed this because startElementNS() in saxutils.py + # cannot handle attr whose name[0] is None, and action/rss_rc.py + # set this to None (ex. name = (None, 'link')). + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + # else try to restore the original prefix from the namespace + name = self._current_context[name[0]] + ":" + name[1] + self._out.write('<' + name) + + for pair in self._undeclared_ns_maps: + self._out.write(' xmlns:%s="%s"' % pair) + self._undeclared_ns_maps = [] + + for (name, value) in attrs.items(): + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + name = self._current_context[name[0]] + ":" + name[1] + self._out.write(' %s=%s' % (name, saxutils.quoteattr(value))) + self._out.write('>') + class RssGenerator(XMLGenerator): default_xmlns = { ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-22 10:52 Message: Logged In: YES user_id=470843 I'm not sure if it's when there's a comment, but mine is certainly dying. http://opag.ca/wiki/RecentChanges?action=rss_rc I'd love a fix for this. I prefer to track wiki changes via the rss feed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 From noreply at sourceforge.net Thu Apr 22 19:12:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 22 19:12:05 2004 Subject: [Moin-devel] [ moin-Bugs-930036 ] RSS feed dies with comments Message-ID: Bugs item #930036, was opened at 2004-04-05 17:24 Message generated for change (Comment added) made by msoulier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kaye (mayhemchaos) Assigned to: Nobody/Anonymous (nobody) Summary: RSS feed dies with comments Initial Comment: The RSS feed feature dies whenever it attempts to process a change that has a comment filled out. This is moin moin 1.2 and 1.2.1: Python Python 2.3.3: /usr/bin/python Linux grunt 2.4.24 #2 Thu Jan 15 14:08:29 PST 2004 i686 MoinMoin Release 1.2.1 [Revision 1.184] Mon Apr 5 14:08:32 2004 ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-22 22:11 Message: Logged In: YES user_id=470843 This patch just worked beautifully for me. Hopefully someone will pay attention and incorporate it! Thanks. ---------------------------------------------------------------------- Comment By: fuji-climb (fuji-climb) Date: 2004-04-21 23:51 Message: Logged In: YES user_id=1014218 I sent a patch for this to the list, but got no response from anyone. This patch solved this issue, at least for me. --- orig/MoinMoin/wikixml/util.py +++ mod/MoinMoin/wikixml/util.py @@ -50,6 +50,32 @@ self.endPrefixMapping(prefix or None) saxutils.XMLGenerator.endDocument(self) + def startElementNS(self, name, qname, attrs): + # this code is a bit modified version of python2.3/xml/sax/saxutils.py + # i needed this because startElementNS() in saxutils.py + # cannot handle attr whose name[0] is None, and action/rss_rc.py + # set this to None (ex. name = (None, 'link')). + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + # else try to restore the original prefix from the namespace + name = self._current_context[name[0]] + ":" + name[1] + self._out.write('<' + name) + + for pair in self._undeclared_ns_maps: + self._out.write(' xmlns:%s="%s"' % pair) + self._undeclared_ns_maps = [] + + for (name, value) in attrs.items(): + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + name = self._current_context[name[0]] + ":" + name[1] + self._out.write(' %s=%s' % (name, saxutils.quoteattr(value))) + self._out.write('>') + class RssGenerator(XMLGenerator): default_xmlns = { ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-21 21:52 Message: Logged In: YES user_id=470843 I'm not sure if it's when there's a comment, but mine is certainly dying. http://opag.ca/wiki/RecentChanges?action=rss_rc I'd love a fix for this. I prefer to track wiki changes via the rss feed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 From David_Robins at klecker.debian.org Thu Apr 22 20:27:07 2004 From: David_Robins at klecker.debian.org (David_Robins at klecker.debian.org) Date: Thu Apr 22 20:27:07 2004 Subject: [Moin-devel] Moin-devel, TONS of piks hes and veedeos waiting 4 u In-Reply-To: References: Message-ID: <4FDJILDA080EFD18@klecker.debian.org> An HTML attachment was scrubbed... URL: From yaghani at mac.com Wed Apr 28 10:51:12 2004 From: yaghani at mac.com (Yusuf Abdulghani) Date: Wed Apr 28 10:51:12 2004 Subject: [Moin-devel] who keeps track of patches and releases Message-ID: <84542E1E-993C-11D8-9C29-0050E4506249@mac.com> Hi, I have seen several patches being submitted to the MOIN developer list to fix bugs and to enhance features. I am wondering who is keeping track of all these and if it will be released in the future MOIN update. BTW, great WIKI implementation. Keep up the good work! Thanks. Yusuf From tw at waldmann-edv.de Wed Apr 28 11:39:04 2004 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Wed Apr 28 11:39:04 2004 Subject: [Moin-devel] who keeps track of patches and releases In-Reply-To: <84542E1E-993C-11D8-9C29-0050E4506249@mac.com> References: <84542E1E-993C-11D8-9C29-0050E4506249@mac.com> Message-ID: <40900688.4010604@waldmann-edv.de> > I have seen several patches being submitted to the MOIN developer list > to fix bugs and to enhance features. I am wondering who is keeping > track of all these and if it will be released in the future MOIN update. Currently that's me and some other guys from #moin irc channel. ;) Every pure & clear & small bug fix will go into the tla branches immediately. If it is unclear if the fix is correct, it might take longer. Correctness means that the fix cures the source of the problem, not only the symptom of the problem. Feature patches might get accepted or not. If a feature patch does not get accepted it doesnt mean it is bad, maybe we only think that it is either too special to go into core code or we are unsure if we maybe want to solve that problem in another (often more general) way or we just don't understand enough of what it is doing or what it is useful for. ;) From jtw87cdggx at interworld.net Wed Apr 28 13:26:01 2004 From: jtw87cdggx at interworld.net (Elease Norene) Date: Wed Apr 28 13:26:01 2004 Subject: [Moin-devel] Keep Ur Small P-E-N-I-S At Home, Dont Bring It Out biological plastered farewell Message-ID: <3tcxgzi2rx-ph6mek5-isjtw87cdggx@interworld.net> myrsine tingent reputably crouton freya nazarene gruel aforenamed endemic foothill roguish overturn deeprooted harmonist cydippida validity longways nonsuch normalness -------------- next part -------------- An HTML attachment was scrubbed... URL: From toh at fuji-climb.org Thu Apr 29 08:26:15 2004 From: toh at fuji-climb.org (Fujio Nobori) Date: Thu Apr 29 08:26:15 2004 Subject: [Moin-devel] who keeps track of patches and releases In-Reply-To: <40900688.4010604@waldmann-edv.de> References: <84542E1E-993C-11D8-9C29-0050E4506249@mac.com> <40900688.4010604@waldmann-edv.de> Message-ID: <200404291525.i3TFPa541449@mail2.inetd.co.jp> Hello, On Wed, Apr 28, 2004 at 09:31:20PM +0200, Thomas Waldmann wrote: > >I have seen several patches being submitted to the MOIN developer list > >to fix bugs and to enhance features. I am wondering who is keeping > >track of all these and if it will be released in the future MOIN update. > > Currently that's me and some other guys from #moin irc channel. ;) > > Every pure & clear & small bug fix will go into the tla branches > immediately. > > If it is unclear if the fix is correct, it might take longer. > Correctness means that the fix cures the source of the problem, not only > the symptom of the problem. I am one of those who sent some patches to the list, and I have been wondering how my patches were treated. Probably my patches were unclear or wrong, or both, but how can I tell if they were unclear or they just got into your Trash folder automatically? :) Just a comment from you is very helpful for me. Anyway, I am not sure where I should submit patches. Mailing lists, MoinMoin Wiki site, or SourceForge? -- il|li q|@.@|p Fujio Nobori m. ( o ) .m email: toh at fuji-climb.org ~~~~~~~~~~~~~ From noreply at sourceforge.net Thu Apr 29 09:37:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 09:37:01 2004 Subject: [Moin-devel] [ moin-Bugs-944660 ] LookupErrorunknown encoding: win-1251 Message-ID: Bugs item #944660, was opened at 2004-04-29 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=944660&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Valentyn Tabota (valik) Assigned to: Nobody/Anonymous (nobody) Summary: LookupErrorunknown encoding: win-1251 Initial Comment: TitleIndex page generates error when win-1251 encoding is used on page. MoinMoin Release 1.2.1 [Revision 1.184] Thu Apr 29 12:32:50 2004 LookupError: unknown encoding: win-1251 __doc__ = 'Base class for lookup errors.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('unknown encoding: win-1251',) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=944660&group_id=8482 From arlo at arlim.org Thu Apr 29 09:49:16 2004 From: arlo at arlim.org (Arlo Belshee) Date: Thu Apr 29 09:49:16 2004 Subject: [Moin-devel] A new feature for Wiki farms. Message-ID: <32920.24.21.201.136.1083257316.spork@webmail.arlim.org> Hi all. I am running a Wiki farm, which I am currently upgrading from 1.1 to 1.2.1. In the process, I thought of a feature that would be really convenient. Thus, I am about to go implement it. However, before I did so, I thought that I'd send a message to the list, with a few questions. Note: I am not on the list (as I don't intend to be a regular MoinMoin developer), so please reply to me personally, rather than on-list. First, let me explain the feature that I'm thinking to add, then I'll list my questions. I have a number of wikis in my farm. These wikis have several things in common, im particular all of the images, stylesheets, plugins, system pages, some ACLs (eg, admin), and a number of other pages (like my tutorial for new, non-technical, english-speaking users). It is fairly simple to make all wikis on the site share most of these resources: anything which doesn't change and can't be overriden by a specific wiki. This includes the code, images, plugins, stylesheets, etc. However, this does not include the pages. So, what I propose to do is to modify the way that MoinMoin finds page files on the disk. Basically, I'm adding a config var 'farm_data_dir', which provides a second place to look for pages. The results of page search, read, create, and write are the same as those for name resolution in Python. Basically, the farm's data dir becomes the globals namespace, while that wiki's data_dir is the locals namesapace. Thus: 1. Listing all pages finds the union of all names in the two sets (union of keys in the dictionaries). 2. Reading a page's raw text off disk is a data access operation: it finds the page in the wiki's data_dir first. If it doesn't exist, it reads it off the farm's data_dir. The page is only "not found" if it doesn't exist in either namespace. 3. There is no global statement, so all pages will be written to the locals namespace. Thus: 3a. Creating a new page that doesn't exist anywhere operates as normal - it creates it in that wiki's data dir. 3b. "Editing" a page that exists only in the farm actually creates a new (occluding) page in the individual wiki's local data dir. The inital value for that variable is accessed by a read operation, so is whatever was in the farm's page. However, saving the new page is implemented as a page creation for that one wiki, and so doesn't affect the wiki farm as a whole. 3c. Editing a page that is part of the individual wiki is performed as normal. 4. The farm's global set is the regular data_dir for another wiki. This wiki is the farm admin wiki. Changes implemented through this wiki operate as normal for this wiki - writing to its local data_dir. This allows the admin to change what is in the global pages, for all wikis. 5. The farm admin may choose, if he desires, to make certain pages (eg, system pages) be non-writable / non-creatable by anyone other than himself. This will prevent them from being overwritten by pages in any of the wikis in the farm (eg, protect the integrity of the Help pages). This is, of course, purely optional on the admin's part. So, now for the questions. First, what do you think about this feature? Are you interested in having it added to the offical MoinMoin codebase? Second, many of you have better knowledge than I of the MoinMoin codebase. I've looked through it, and this change looks to be rather invasive - with a number of potentially bizarre side effects. Do any of you know of an elegant way to make the change? It looks to me to require changes to Page, PageEditor, and several functions in wikiutil (getPageList, getPageDict, getBackupList, getSysPage, getHomePage, and getPagePath. Potentially also isSysPage, etc). Is there actually a fracture point already in the code for this sort of change, which I'm just not seeing? Do any of you have any other suggestions as I set about this? Is there anything in general that I should keep in mind (I've tinkered with the MoinMoin code before, but am not a developer of it)? Thanks for your help as I work on this. Arlo From tw-public at gmx.de Thu Apr 29 10:36:06 2004 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu Apr 29 10:36:06 2004 Subject: [Moin-devel] who keeps track of patches and releases In-Reply-To: <200404291525.i3TFPa541449@mail2.inetd.co.jp> References: <84542E1E-993C-11D8-9C29-0050E4506249@mac.com> <40900688.4010604@waldmann-edv.de> <200404291525.i3TFPa541449@mail2.inetd.co.jp> Message-ID: <40914942.80503@gmx.de> >I am one of those who sent some patches to the list, and I >have been wondering how my patches were treated. > > I have looked into the rss_rc fix. The problem is that I am no XML nor RSS/RDF expert and so I was quite unsure if overloading a library routine to fix that "None" problem is correct. So I decided to just remove that "None" stuff at the source, just commenting that one line out (like it was done in the other half of that "if" there) until that is cleared. The fix will be in 1.2.2. Although we did not simply apply your patch, it helped us tracking the problem. Thanks! The underlay directory stuff is nice for separating help pages. It wasn't included yet because it is unsure if we maybe solve that in a completely different way after integrating multilang (multilang separates different language versions of the same page, so we maybe can also solve separating different language help pages after doing multilang). Multilang isn't integrated yet, so this will take some time.... >Probably my patches were unclear or wrong, or both, but how >can I tell if they were unclear or they just got into your >Trash folder automatically? :) Just a comment from you is >very helpful for me. > > They are in my moin-email folder, not in trash ;) >Anyway, I am not sure where I should submit patches. >Mailing lists, MoinMoin Wiki site, or SourceForge? > > It doesn't matter much, although in the wiki or on SF they maybe don't get lost that easily if they can't get processed immediately. From noreply at sourceforge.net Thu Apr 29 10:41:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 10:41:09 2004 Subject: [Moin-devel] [ moin-Bugs-944660 ] LookupErrorunknown encoding: win-1251 Message-ID: Bugs item #944660, was opened at 2004-04-29 18:36 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=944660&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Valentyn Tabota (valik) Assigned to: Nobody/Anonymous (nobody) Summary: LookupErrorunknown encoding: win-1251 Initial Comment: TitleIndex page generates error when win-1251 encoding is used on page. MoinMoin Release 1.2.1 [Revision 1.184] Thu Apr 29 12:32:50 2004 LookupError: unknown encoding: win-1251 __doc__ = 'Base class for lookup errors.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('unknown encoding: win-1251',) ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-29 19:40 Message: Logged In: YES user_id=100649 I need either the complete backtrace or a public url where that error happens (so I can see the error backtrace there). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=944660&group_id=8482 From noreply at sourceforge.net Thu Apr 29 10:42:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 10:42:00 2004 Subject: [Moin-devel] [ moin-Bugs-930036 ] RSS feed dies with comments Message-ID: Bugs item #930036, was opened at 2004-04-05 23:24 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Robert Kaye (mayhemchaos) Assigned to: Nobody/Anonymous (nobody) Summary: RSS feed dies with comments Initial Comment: The RSS feed feature dies whenever it attempts to process a change that has a comment filled out. This is moin moin 1.2 and 1.2.1: Python Python 2.3.3: /usr/bin/python Linux grunt 2.4.24 #2 Thu Jan 15 14:08:29 PST 2004 i686 MoinMoin Release 1.2.1 [Revision 1.184] Mon Apr 5 14:08:32 2004 ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-29 19:41 Message: Logged In: YES user_id=100649 The problematic code will be removed in 1.2.2. ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-23 04:11 Message: Logged In: YES user_id=470843 This patch just worked beautifully for me. Hopefully someone will pay attention and incorporate it! Thanks. ---------------------------------------------------------------------- Comment By: fuji-climb (fuji-climb) Date: 2004-04-22 05:51 Message: Logged In: YES user_id=1014218 I sent a patch for this to the list, but got no response from anyone. This patch solved this issue, at least for me. --- orig/MoinMoin/wikixml/util.py +++ mod/MoinMoin/wikixml/util.py @@ -50,6 +50,32 @@ self.endPrefixMapping(prefix or None) saxutils.XMLGenerator.endDocument(self) + def startElementNS(self, name, qname, attrs): + # this code is a bit modified version of python2.3/xml/sax/saxutils.py + # i needed this because startElementNS() in saxutils.py + # cannot handle attr whose name[0] is None, and action/rss_rc.py + # set this to None (ex. name = (None, 'link')). + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + # else try to restore the original prefix from the namespace + name = self._current_context[name[0]] + ":" + name[1] + self._out.write('<' + name) + + for pair in self._undeclared_ns_maps: + self._out.write(' xmlns:%s="%s"' % pair) + self._undeclared_ns_maps = [] + + for (name, value) in attrs.items(): + if name[0] is None: + # if the name was not namespace-scoped, use the unqualified part + name = name[1] + else: + name = self._current_context[name[0]] + ":" + name[1] + self._out.write(' %s=%s' % (name, saxutils.quoteattr(value))) + self._out.write('>') + class RssGenerator(XMLGenerator): default_xmlns = { ---------------------------------------------------------------------- Comment By: Michael P. Soulier (msoulier) Date: 2004-04-22 03:52 Message: Logged In: YES user_id=470843 I'm not sure if it's when there's a comment, but mine is certainly dying. http://opag.ca/wiki/RecentChanges?action=rss_rc I'd love a fix for this. I prefer to track wiki changes via the rss feed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=930036&group_id=8482 From noreply at sourceforge.net Thu Apr 29 10:45:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 10:45:02 2004 Subject: [Moin-devel] [ moin-Bugs-935683 ] Standalone server bug determining static files Message-ID: Bugs item #935683, was opened at 2004-04-15 17:01 Message generated for change (Settings changed) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) >Assigned to: Thomas Waldmann (thomaswaldmann) Summary: Standalone server bug determining static files Initial Comment: The standalone server looks at the filename extension to determine if a file should be delegated to the static server. However, it doesn't chop off the query string, so if you have a URL such as /PageName?action=attach&target=overview.gif, the extension is determined to be .gif and the static server tries to access PageName?action=... . See the attached patch for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 From noreply at sourceforge.net Thu Apr 29 10:52:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 10:52:13 2004 Subject: [Moin-devel] [ moin-Bugs-935683 ] Standalone server bug determining static files Message-ID: Bugs item #935683, was opened at 2004-04-15 17:01 Message generated for change (Comment added) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Thomas Waldmann (thomaswaldmann) Summary: Standalone server bug determining static files Initial Comment: The standalone server looks at the filename extension to determine if a file should be delegated to the static server. However, it doesn't chop off the query string, so if you have a URL such as /PageName?action=attach&target=overview.gif, the extension is determined to be .gif and the static server tries to access PageName?action=... . See the attached patch for a fix. ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-29 19:51 Message: Logged In: YES user_id=100649 Thanks for the patch. The fix will be in arch soon (and also in 1.2.2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935683&group_id=8482 From noreply at sourceforge.net Thu Apr 29 11:13:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 29 11:13:13 2004 Subject: [Moin-devel] [ moin-Bugs-935700 ] Standalone server: fix file uploads Message-ID: Bugs item #935700, was opened at 2004-04-15 17:23 Message generated for change (Settings changed) made by thomaswaldmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935700&group_id=8482 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Standalone server: fix file uploads Initial Comment: The standalone server doesn't set the content-type, which means that multipart/form-data doesn't work, which means that file uploads don't work, which means that creating attachments doesn't work. The attached patch sets content-type, and adds an inefficient .readline() method because the 'cgi' module needs it. ---------------------------------------------------------------------- >Comment By: Thomas Waldmann (thomaswaldmann) Date: 2004-04-29 20:12 Message: Logged In: YES user_id=100649 Thanks for the patch. It will be in arch soon and also in 1.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108482&aid=935700&group_id=8482 From tw-public at gmx.de Thu Apr 29 17:00:06 2004 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu Apr 29 17:00:06 2004 Subject: [Moin-devel] A new feature for Wiki farms. In-Reply-To: <32920.24.21.201.136.1083257316.spork@webmail.arlim.org> References: <32920.24.21.201.136.1083257316.spork@webmail.arlim.org> Message-ID: <4091A350.4020109@gmx.de> Hi, >a message to the list, with a few questions. Note: I am not on the list (as I >don't intend to be a regular MoinMoin developer), so please reply to me >personally, rather than on-list. > > Maybe you should subscribe to the list, even as non-regular developer. >1. Listing all pages finds the union of all names in the two sets (union of >keys in the dictionaries). > >2. Reading a page's raw text off disk is a data access operation: it finds the >page in the wiki's data_dir first. If it doesn't exist, it reads it off the >farm's data_dir. The page is only "not found" if it doesn't exist in either >namespace. > >3. There is no global statement, so all pages will be written to the locals >namespace. Thus: > > 3a. Creating a new page that doesn't exist anywhere operates as normal - it >creates it in that wiki's data dir. > > 3b. "Editing" a page that exists only in the farm actually creates a new >(occluding) page in the individual wiki's local data dir. The inital value >for that variable is accessed by a read operation, so is whatever was in the >farm's page. However, saving the new page is implemented as a page creation >for that one wiki, and so doesn't affect the wiki farm as a whole. > > 3c. Editing a page that is part of the individual wiki is performed as normal. > > > Until here, it is about what Fujio's underlay_dir patch does. It was posted to the list not long ago, maybe you can find it in the archives. >4. The farm's global set is the regular data_dir for another wiki. This wiki >is the farm admin wiki. Changes implemented through this wiki operate as >normal for this wiki - writing to its local data_dir. This allows the admin to >change what is in the global pages, for all wikis. > > > Nice idea. >5. The farm admin may choose, if he desires, to make certain pages (eg, system >pages) be non-writable / non-creatable by anyone other than himself. This will >prevent them from being overwritten by pages in any of the wikis in the farm >(eg, protect the integrity of the Help pages). This is, of course, purely >optional on the admin's part. > > This maybe should be integrated with ACL system in a sane, yet to be defined, way. Maybe don't do that in first implementation. >First, what do you think about this feature? Are you interested in having it >added to the offical MoinMoin codebase? > > Sorry, that can't be decided now. As for Fujio's patch, we first have to integrate some other stuff (multilang). After that, I think we can decide better whether to integrate such stuff (and how) or not. >Second, many of you have better knowledge than I of the MoinMoin codebase. >I've looked through it, and this change looks to be rather invasive - with a >number of potentially bizarre side effects. Do any of you know of an elegant >way to make the change? > Talk to Fujio, he is maybe interested in that NOW and he already did quite some of what you want. greetings, Thomas From lan at falleagle.net Fri Apr 30 13:18:05 2004 From: lan at falleagle.net (Lan Barnes) Date: Fri Apr 30 13:18:05 2004 Subject: [Moin-devel] Area level edit security Message-ID: <20040430201747.GA22931@falleagle.net> I'm new to the list and apologize in advance for asking a question which I suspect is a FAQ. Nevertheless, I couldn't find an answer in my search of the archive. We are planning to use a wiki (MoinMoin) as an adjunct to a software configuration management system in my company. The code repository (Perforce) and issue/bug tracking (DevTrack) components will be handled by proprietary SW (actually, I believe DevTrack is open source and we have a support contract with the primary developers). We want to use a wiki to gather ancillary data in a viewable and editable format. Each project will have a link on an entry page that will, in turn, have links to the project's: 1. Manifest (purpose, developers, testers, open dates, baseline tag, etc) 2. Build procedures 3. Schedule and completion chart 4. Task summary 5. Code reviews So far so good, but here are the hacks I could use help on: 1. We want the whole system to be world readable, but for the project pages to be editable only by members of the project. I have been searching the code for exactly where the [Edit] button on a page kicks off the editing process so I can hack it to check a list of user names and return w/o action if the requester isn't on the list. I'm learning Python as I go (not the best way to do it!), and find the dereferencing of OO code obscuring. I'd love a hint. Or clue -- I'm not proud. 2. We would like to archive each project's pages in our repository (allowing us to tag the wiki contents with build and release numbers corresponding to the code tags) at regular (e.g. nightly) and irregular (upon a build) intervals. I am trying to understand the relationship between the .../data/text/ and the .../data/text/cache/pagelinks/. Are both necessary on restore? I'll be working on it this weekend, so Saturday replies are as welcome as any others. For the record, we are a M$ house but are running our Moin server on Apache over Red Hat 9. Which I think is gonna make this a lot easier for me in the long run. TIA for any help, -- Lan Barnes lan at falleagle.net Linux Guy, SCM Specialist 858-354-0616 From tw-public at gmx.de Fri Apr 30 13:59:01 2004 From: tw-public at gmx.de (Thomas Waldmann) Date: Fri Apr 30 13:59:01 2004 Subject: [Moin-devel] Area level edit security In-Reply-To: <20040430201747.GA22931@falleagle.net> References: <20040430201747.GA22931@falleagle.net> Message-ID: <4092CA44.6050608@gmx.de> >1. We want the whole system to be world readable, > This is the default in wikis. >but for the project pages to be editable only by members of the project. > If you really need that, you can make some ProjectXxxGroup pages and put ACLs on the project pages. Be aware that it is more the wiki way to let it world writeable and just revert unwanted changes. >2. We would like to archive each project's pages in our repository >(allowing us to tag the wiki contents with build and release numbers >corresponding to the code tags) at regular (e.g. nightly) and irregular >(upon a build) intervals. I am trying to understand the relationship >between the .../data/text/ and the >.../data/text/cache/pagelinks/. Are both necessary on restore? > > Everything in cache/ can (and will) be automatically rebuilt. So you only need to save text/ and pages/ (attachments) and maybe backup/ (old page versions). Also editlog and user/ if you want to reproduce who did what. >For the record, we are a M$ house > Sincere condolences. X) >but are running our Moin server on Apache over Red Hat 9. > Hey, at least one stable machine, hehe ;) SCNR.