From noreply at sourceforge.net  Fri Apr  4 01:56:16 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Apr  4 01:56:16 2003
Subject: [Moin-devel] [ moin-Feature Requests-487605 ] Standards-conformant HTML output
Message-ID: <E191OAY-0006AL-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #487605, was opened at 2001-11-30 18:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358482&aid=487605&group_id=8482

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Christian Reiniger (creinig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Standards-conformant HTML output

Initial Comment:
Try browsing moinmoin pages with konqueror or, if you're 
really masochistic, piping them through 
http://validator.w3.org/
konqueror especially has big problems with <a name> tags 
without proper </a>

Proper XHTML would be *really* cool, but anything 
rendering correctly (and looking good) will do for the start.

I'd send a patch (looking at MoinMoin/formatter/text*.py it 
doesn't seem too difficult), but I have zero Python 
knowledge..


----------------------------------------------------------------------

Comment By: Thomas Lorenz (rockfrog)
Date: 2003-04-04 12:11

Message:
Logged In: YES 
user_id=648745

This is a really good idea. The non-conformant HTML-output
severely limits the usage of own cascading style sheets, e.g.

a
{
    text-decoration: underline;
}

yields some very ugly results in the page preview.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=358482&aid=487605&group_id=8482



From noreply at sourceforge.net  Sat Apr  5 08:57:02 2003
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Apr  5 08:57:02 2003
Subject: [Moin-devel] [ moin-Patches-715905 ] Represent language names as Unicode strings
Message-ID: <E191rDA-0003pH-00@sc8-sf-web3.sourceforge.net>

Patches item #715905, was opened at 2003-04-05 19:12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308482&aid=715905&group_id=8482

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L?wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Represent language names as Unicode strings

Initial Comment:
Currently, if the charset is not Latin-1, the language
names Fran?ais and Portugu?s come out incorrectly.

This patch fixes this, by:

1. Representing the language names as Unicode strings
in source code.

2. Converting them to the target character set when
creating the userform

3. Adding a new function i18n.htmlQuote, which works
like cgi.escape, but also encodes Unicode strings. If
the Unicode string cannot be encoded in config.charset,
it uses HTML character references.

None of the currenlty-English language names (Hebrew,
Japanese, etc.) have been converted; if this is done,
the encoding of the file needs to change from Latin-1
to UTF-8. Since Python 2.x for x<3 only supports
Latin-1 in Unicode literals, the native-language names
of the language need to be changed like so: Replace

  u"Hebrew"

with

  unicode("<Hebrew name of Hebrew>", "utf-8")

(A local function u() might come handy for that)





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=308482&aid=715905&group_id=8482



From leslie.barnes at amd.com  Thu Apr 17 11:54:11 2003
From: leslie.barnes at amd.com (Leslie A. Barnes)
Date: Thu Apr 17 11:54:11 2003
Subject: [Moin-devel] subwikis/subdirectories
Message-ID: <200304171853.LAA00305@lx-desk41.amd.com>

 
 Is there any thought/plan with MoinMoin on supporting sub-directories
 or sub-wikis?  One argument I'm having right now is over TWiki vs
 MoinMoin.  TWiki has a single level of indirection with "webs" or
 subwikis and is moving towards a fully hierarchical design.  Has
 there been discussion along these lines before, and what is the
 concensus?

 For example, instead of having "data/text", have "data/text/dir1",
 "data/text/dir2" etc.  The current subpage "/MySubPage" syntax could
 support this.  My main issue is over scaleability as the number of
 pages increases.  However, there would be a lot of side-benefits as
 far as directing searches to sub-directories only etc.  It would be a
 powerful organizational feature.

 thanks




From jh at web.de  Thu Apr 17 11:58:16 2003
From: jh at web.de (Juergen Hermann)
Date: Thu Apr 17 11:58:16 2003
Subject: [Moin-devel] widget/html.py
Message-ID: <E196EZx-0002ne-00@smtp.web.de>

Hi!

If someone is looking for boring work over Easter, the above modules 
needs the attributr lists completed. If you want to take over the job, 
mail me please.


Ciao, J?rgen





From jh at web.de  Thu Apr 17 12:04:13 2003
From: jh at web.de (Juergen Hermann)
Date: Thu Apr 17 12:04:13 2003
Subject: [Moin-devel] subwikis/subdirectories
In-Reply-To: <200304171853.LAA00305@lx-desk41.amd.com>
Message-ID: <E196EeI-0002pl-00@smtp.web.de>

On Thu, 17 Apr 2003 11:53:11 -0700, Leslie A. Barnes wrote:

> Is there any thought/plan with MoinMoin on supporting sub-directories
> or sub-wikis?  One argument I'm having right now is over TWiki vs
> MoinMoin. 

Nothing concrete, but since our company wiki is growing fast (currently 
2500 pages) there will be optimizations.


Ciao, J?rgen





From leslie.barnes at amd.com  Thu Apr 17 12:11:10 2003
From: leslie.barnes at amd.com (Leslie A. Barnes)
Date: Thu Apr 17 12:11:10 2003
Subject: [Moin-devel] subwikis/subdirectories
In-Reply-To: <E196EeI-0002pl-00@smtp.web.de> (jh@web.de)
References: <E196EeI-0002pl-00@smtp.web.de>
Message-ID: <200304171909.MAA01446@lx-desk41.amd.com>

 A heirarchical design has a lot of advantages for multi-group
 projects, wikis within wikis etc.  But, that would be a lot of work
 from the current MoinMoin codebase.
  




From tw at waldmann-edv.de  Thu Apr 17 12:18:28 2003
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu Apr 17 12:18:28 2003
Subject: [Moin-devel] subwikis/subdirectories
In-Reply-To: <200304171853.LAA00305@lx-desk41.amd.com>
References: <200304171853.LAA00305@lx-desk41.amd.com>
Message-ID: <3E9EFD8F.8010208@waldmann-edv.de>

> Is there any thought/plan with MoinMoin on supporting sub-directories
> or sub-wikis?
>
Thoughts: yes.

> One argument I'm having right now is over TWiki vs
> MoinMoin.  TWiki has a single level of indirection with "webs" or
> subwikis and is moving towards a fully hierarchical design.
>
Having a full hierachical design can get you (or rather some of your 
wiki's users) lost in this hierarchy and it adds complexity for the 
user, who has not only to think about the page name, but also where to 
put his page into that hierarchy of sub-wikis.

OTOH, easy creation of sub-wikis would be nice for wiki hosting 
providers like us. It would also be nice IF used with care.

> For example, instead of having "data/text", have "data/text/dir1",
> "data/text/dir2" etc.  The current subpage "/MySubPage" syntax could
> support this.
>
Yes, but that would make searching and page name pattern maching more 
complicated to implement.

> My main issue is over scaleability as the number of
> pages increases.
>
How much pages do you have? At linuxwiki.org we currently have about 
1600 pages and 17000 backup copies and we do not have any performance 
issues yet caused by page count or filesystem.

I also have concerns about performance, but it is more regarding CPU 
load when access rate increases. But there is quite a big performance 
boost in sight after 1.1 ("persistence"), so I don't worry.

greetings,

Thomas





From Toby.Knudsen at RocketSoftware.com  Thu Apr 17 14:44:10 2003
From: Toby.Knudsen at RocketSoftware.com (Toby Knudsen)
Date: Thu Apr 17 14:44:10 2003
Subject: [Moin-devel] I've got issues!
Message-ID: <9BFCEB1E1A274A49A866B6E9290752D6A811E3@owa.rocketsoftware.com>

Hello,

I'm Toby Knudsen and I last spoke to some Moin developers on #moin about three weeks ago.  I've not been idle in that time!  I gave a presentation of Moin at our Tuesday company meeting and have modified userform to allow logins to my liking, to only discover it was already in cvs.

We've used Moin since January 14 and already have three thousand pages (not page modifications) and two thousand attachments uploaded.  The CEO uses it and requests its use, the people who made fun of it are using it, pretty much everyone is slated to use it.

My company says they will pay for me to spend some time developing Moin features we need and otherwise assisting the project.  I've a strong interest in writing unit tests, if you have a need there...

Otherwise, I have these interests:

	-Getting Moin to authenticate from mod_auth_ldap

	-People get confused by the login ID.  What's the need of this item?

	-ACL's are strongly desired.

My services are at your disposal, let me know about any specific etiquette and where the need lies in this project.

Toby




From tw at waldmann-edv.de  Thu Apr 17 15:01:09 2003
From: tw at waldmann-edv.de (Thomas Waldmann)
Date: Thu Apr 17 15:01:09 2003
Subject: [Moin-devel] I've got issues!
In-Reply-To: <9BFCEB1E1A274A49A866B6E9290752D6A811E3@owa.rocketsoftware.com>
References: <9BFCEB1E1A274A49A866B6E9290752D6A811E3@owa.rocketsoftware.com>
Message-ID: <3E9F23F1.6090905@waldmann-edv.de>

Hi Toby,

>have modified userform to allow logins to my liking, to only discover it was already in cvs.
>
If you do development, you should always use CVS head.

>We've used Moin since January 14 and already have three thousand pages (not page modifications) and two thousand attachments uploaded.  The CEO uses it and requests its use, the people who made fun of it are using it, pretty much everyone is slated to use it.
>
Great.

>My company says they will pay for me to spend some time developing Moin features
>
Even greater ;)

>I've a strong interest in writing unit tests, if you have a need there...
>
Juergen will love you ;)

>Otherwise, I have these interests:
>
>	-Getting Moin to authenticate from mod_auth_ldap
>
Sounds nice.

>	-People get confused by the login ID.  What's the need of this item?
>
It is simply a unique id to identify your settings stored on the server. 
But other methods are already in the works.

>	-ACL's are strongly desired.
>
I am just waiting to have authentication and 1.1 release to continue 
working on that in post-1.1 cvs.

>My services are at your disposal, let me know about any specific etiquette and where the need lies in this project.
>
Before starting to implement something, talk about it in the moinmoin 
wiki or on #moin (or here, although I personally dislike long 
discussions on mailing lists).

greetings,

Thomas





From jh at web.de  Thu Apr 17 20:41:01 2003
From: jh at web.de (Juergen Hermann)
Date: Thu Apr 17 20:41:01 2003
Subject: [Moin-devel] I've got issues!
In-Reply-To: <9BFCEB1E1A274A49A866B6E9290752D6A811E3@owa.rocketsoftware.com>
Message-ID: <E196MjD-0000LC-00@smtp.web.de>

On Thu, 17 Apr 2003 17:43:44 -0400, Toby Knudsen wrote:

>My company says they will pay for me to spend some time developing 
Moin features we need and otherwise assisting the project.  I've a 
strong interest in writing unit tests, if you have a need there...

Certainly we have a need there. I'll try to improve the "meta" docs of 
the project in the next weeks, but you can start off by reading (and 
improving, it's a wiki, you know ;) what's already there on

http://twistedmatrix.com/users/jh.twistd/moin/moin.cgi/MoinDev

I _do_ plan to extend the amount of developers on the project to get 
more inertia, but at the same time we need to get the infrastructure in 
place to not lose control of things (unit tests are a part of that). 

I especially want to avoid bad feature karma. Pretty much like with 
Python itself, once a feature is added, it has to be maintained; that 
is one reason for the "Markets", so we can test whether a feature is 
general enough to be part of the core distro.

Great to have you on the team. The problems you face are the same we 
have with the use in our intranet, which means we can work together on 
that topic (intranet / mass usage improvements).

Ciao, J?rgen





From leslie.barnes at amd.com  Fri Apr 18 08:48:04 2003
From: leslie.barnes at amd.com (Leslie A. Barnes)
Date: Fri Apr 18 08:48:04 2003
Subject: [Moin-devel] MoinMoin mods
Message-ID: <200304181547.IAA10269@lx-desk41.amd.com>

 We've made a couple of minor changes to MoinMoin locally.

 1) allow attachments to be quoted.

    eg.  attach:"my file name.xls"

    which some people had asked for.  It's a straightforward change
    to url_rule regexp and attachment() in parser/wiki.py

 2) I added a "DeepSiteMap" action, which prints the entire site map,
but filters out system pages.  Maybe not useful for very large sites,
but for our current site it is good.  It uses a slightly modified
LocalSiteMap which doesn't terminate the recursion.  DeepSiteMap just
inherits from the modified LocalSiteMap, changing a parameter.

 Any interest in these for the general distribution?

 thanks




From jh at web.de  Fri Apr 18 10:17:18 2003
From: jh at web.de (Juergen Hermann)
Date: Fri Apr 18 10:17:18 2003
Subject: [Moin-devel] MoinMoin mods
In-Reply-To: <200304181547.IAA10269@lx-desk41.amd.com>
Message-ID: <E196ZT7-0006NR-00@smtp.web.de>

On Fri, 18 Apr 2003 08:47:15 -0700, Leslie A. Barnes wrote:

> 1) allow attachments to be quoted.
>
>    eg.  attach:"my file name.xls"
>
>    which some people had asked for.  It's a straightforward change
>    to url_rule regexp and attachment() in parser/wiki.py
>
> 2) I added a "DeepSiteMap" action, which prints the entire site map,
>but filters out system pages.  Maybe not useful for very large sites,
>but for our current site it is good.  It uses a slightly modified
>LocalSiteMap which doesn't terminate the recursion.  DeepSiteMap just
>inherits from the modified LocalSiteMap, changing a parameter.
>
> Any interest in these for the general distribution?

Send me a patch (diff -u) for 1, and put 2 on the ActionMarket.


Ciao, J?rgen





From magnus at thinkware.se  Sat Apr 26 03:24:13 2003
From: magnus at thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=)
Date: Sat Apr 26 03:24:13 2003
Subject: [Moin-devel] Intermap: wxPython wiki
Message-ID: <5.2.1.1.0.20030426122009.026838c8@www.thinkware.se>

I suppose "http://wiki.wxpython.org/index.cgi/" should be in
intermap.txt... I'm not sure about the procudure for this.



--
Magnus Lycka (It's really Lyck&aring;), magnus at thinkware.se
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program 




From pgd-karolinali at algonet.se  Mon Apr 28 01:53:06 2003
From: pgd-karolinali at algonet.se (Karolina Lindqvist)
Date: Mon Apr 28 01:53:06 2003
Subject: [Moin-devel] Macro that generates a dyamic png
Message-ID: <200304281002.06401.pgd-karolinali@algonet.se>

I spent a day, a few weeks ago, to develop a very specialised macro for my 
wiki. It takes a description, and create a graphic picture from it, on the 
fly, with the help of gd. I tried a macro first, but I could not figure out 
any way to send the .png back to display it, without writing it to disk 
first. Finally I made it into an action, since they can give a png on the 
fly. But now the action name shows up on the bottom of each page, and it is 
not really an action you can do, but a macro.

Here is an example how I call it:

 [[HTML(<img 
src="http://shakti.ath.cx/ShaktiWiki/?action=WeaveImage&box=20&solv=0:1&tramp=121212&knyt=x-:-x">)]]

So what I would need, is either how to send a PNG 'on the fly' from a macro, 
or how to make an action that is not listed at the bottom of all pages.

Karolina




From nick at rockstarvancouver.com  Mon Apr 28 10:34:02 2003
From: nick at rockstarvancouver.com (Nick Trout)
Date: Mon Apr 28 10:34:02 2003
Subject: [Moin-devel] Macro that generates a dyamic png
Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB428@iggy.rockstarvancouver.com>

> So what I would need, is either how to send a PNG 'on the fly' from a
macro, 
or how to make an action that is not listed at the bottom of all pages.

I haven't tried this but you could write the PNG to the page's
attachment directory and return the attachment name as a link (eg. <img
src="attachment-name">) from the macro. You could check the page
timestamp and PNG timestamp to decide whether to recreate the PNG after
a page save.

Regards,
Nick




From festifn at rupert.informatik.uni-stuttgart.de  Mon Apr 28 10:49:49 2003
From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi)
Date: Mon Apr 28 10:49:49 2003
Subject: [Moin-devel] Macro that generates a dyamic png
In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB428@iggy.rockstarvancouver.com>
Message-ID: <Pine.GHP.4.33.0304281940480.14141-100000@rupert.informatik.uni-stuttgart.de>


On Mon, 28 Apr 2003, Nick Trout wrote:

>
> > So what I would need, is either how to send a PNG 'on the fly' from a
> macro,
> or how to make an action that is not listed at the bottom of all pages.
>
> I haven't tried this but you could write the PNG to the page's
> attachment directory and return the attachment name as a link (eg. <img
> src="attachment-name">) from the macro. You could check the page
> timestamp and PNG timestamp to decide whether to recreate the PNG after
> a page save.

Implement an action that returns the png and and return al link to this
action as source of the image link:

<img src="?action=shown_picture">

See the Code of the StatsChart macro

Perhap you would want to use caching. See the MoinMoin/caching.py


	cu

		Florian Festi




From jh at web.de  Mon Apr 28 11:27:55 2003
From: jh at web.de (Juergen Hermann)
Date: Mon Apr 28 11:27:55 2003
Subject: [Moin-devel] Macro that generates a dyamic png
In-Reply-To: <200304281002.06401.pgd-karolinali@algonet.se>
Message-ID: <E19ADJS-0002Dk-00@smtp.web.de>

On Mon, 28 Apr 2003 10:02:04 +0200, Karolina Lindqvist wrote:

>So what I would need, is either how to send a PNG 'on the fly' from a macro, 
>or how to make an action that is not listed at the bottom of all pages.

CVS head contains code for macros to have their own actions, see RecentChanges 
and "do_rss_rc".

Alternatively, make your acton all lowercase and it's NOT put into the footer.


Ciao, J?rgen





From pgd-karolinali at algonet.se  Tue Apr 29 01:03:02 2003
From: pgd-karolinali at algonet.se (Karolina Lindqvist)
Date: Tue Apr 29 01:03:02 2003
Subject: [Moin-devel] Macro that generates a dyamic png
In-Reply-To: <E19ADJS-0002Dk-00@smtp.web.de>
References: <E19ADJS-0002Dk-00@smtp.web.de>
Message-ID: <200304291002.23326.pgd-karolinali@algonet.se>

m?ndagen den 28 april 2003 20.25 skrev Juergen Hermann:

> CVS head contains code for macros to have their own actions, see
> RecentChanges and "do_rss_rc".

I will check that out.


> Alternatively, make your acton all lowercase and it's NOT put into the
> footer.

That was a simple solution. I'll do that.

Thank you.

Karolina




From pgd-karolinali at algonet.se  Tue Apr 29 01:03:06 2003
From: pgd-karolinali at algonet.se (Karolina Lindqvist)
Date: Tue Apr 29 01:03:06 2003
Subject: [Moin-devel] Macro that generates a dyamic png
In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB428@iggy.rockstarvancouver.com>
References: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB428@iggy.rockstarvancouver.com>
Message-ID: <200304291002.39232.pgd-karolinali@algonet.se>

m?ndagen den 28 april 2003 19.33 skrev Nick Trout:

> I haven't tried this but you could write the PNG to the page's
> attachment directory and return the attachment name as a link (eg. <img
> src="attachment-name">) from the macro. You could check the page
> timestamp and PNG timestamp to decide whether to recreate the PNG after
> a page save.

I tried that, to put the png file in a temporary directory. It worked once, 
but when the same thing was called twice on the same page it didn't work.  
And then, if it would ever happen that the same page was called two times at 
the same time, it would not work either.

Karolina




From nick at rockstarvancouver.com  Tue Apr 29 11:12:04 2003
From: nick at rockstarvancouver.com (Nick Trout)
Date: Tue Apr 29 11:12:04 2003
Subject: [Moin-devel] Macro that generates a dyamic png
Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB42D@iggy.rockstarvancouver.com>

m?ndagen den 28 april 2003 19.33 skrev Nick Trout:
> I haven't tried this but you could write the PNG to the page's 
> attachment directory and return the attachment name as a link (eg. 
> <img
> src="attachment-name">) from the macro. You could check the page
> timestamp and PNG timestamp to decide whether to recreate the PNG
after
> a page save.

K> I tried that, to put the png file in a temporary directory. It worked
once, 
but when the same thing was called twice on the same page it didn't
work.  
And then, if it would ever happen that the same page was called two
times at 
the same time, it would not work either.


The idea was that the macro creates a PNG and writes it to the
<wikiname>/data/pages/attachments directory. The macro then returns a
link to the attachment, just as the "attachment:<attachment name>"
markup works.

Alternatively you could place the macro in a page, and have it return a
blank string, which means it is invisible. You could then just reference
them as many times as you like using the attachment markup previously
described.

Doing it this way would mean you get the chance to update the PNG either
every time the page is rendered (and by comparing timestamps you might
choose to only updated on a page save). Using actions I believe you
would have to call the action explicitly to create the PNG attachment in
order to include it, ie. Actions are only called when the user calls
them. I don't think you can call actions from a page using mark up. You
could create content using processors however, but I don't think you can
pass parameters to them.

--Nick







From festifn at rupert.informatik.uni-stuttgart.de  Tue Apr 29 23:10:06 2003
From: festifn at rupert.informatik.uni-stuttgart.de (Florian Festi)
Date: Tue Apr 29 23:10:06 2003
Subject: [Moin-devel] Macro that generates a dyamic png
In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB42D@iggy.rockstarvancouver.com>
Message-ID: <Pine.GHP.4.33.0304300757460.29746-100000@rupert.informatik.uni-stuttgart.de>

> The idea was that the macro creates a PNG and writes it to the
> <wikiname>/data/pages/attachments directory. The macro then returns a
> link to the attachment, just as the "attachment:<attachment name>"
> markup works.

I think this is really ugly. Your solution should hide the implementation
from the user and should not have sideeffects as changing the attached
files.

> Alternatively you could place the macro in a page, and have it return a
> blank string, which means it is invisible. You could then just reference
> them as many times as you like using the attachment markup previously
> described.

Even uglier.

As allready said, make the macro return

<img src="?action=build_png>">

If you don't want to generate the picture every time use
MoinMoin/caching.py

Everything else is a bad hack!

	cu

		Florina Festi




From nick at rockstarvancouver.com  Wed Apr 30 09:05:13 2003
From: nick at rockstarvancouver.com (Nick Trout)
Date: Wed Apr 30 09:05:13 2003
Subject: [Moin-devel] Macro that generates a dyamic png
Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F80CB433@iggy.rockstarvancouver.com>


NDT> The idea was that the macro creates a PNG and writes it to the 
> <wikiname>/data/pages/attachments directory. The macro then returns a 
> link to the attachment, just as the "attachment:<attachment name>" 
> markup works.

FF> I think this is really ugly. Your solution should hide the
implementation from the user and should not have sideeffects as changing
the attached files.

I was just clarifying my explanation as it didn't look like the the
poster had tried what I explained. It's a matter of opinion whether it
is ugly or not. It does the job and is all contained on one place.