Permanent Comment Links --MikeMell 2003/05/06 00:37 GMT
what is the vision for "permanent comment links"? How should they work? How are they like purple numbers? I'll try to keep those goals in mind as I build.

Permanent Comment Links --SimonMichael, 2003/05/06 01:16 GMT
Great, welcome Mike.

Just that it should be possible to address an individual comment with some kind of sensible permanent url, similar to what bloggers use perhaps.

For zwiki I see the purple numbers thing as possibly two parts - 1. it would be nice for one or all of Zwiki's markup modes to generate Purple/Augment-style anchors automatically. 2. it would be nice, as a user option, for Zwiki to display any named anchors (generated by 1, and any others added by the user) in the Purple style.

one way to hook in --SimonMichael, 2003/05/06 01:29 GMT in cvs has a placeholder addPurpleNumbers, if it helps.

rename --SimonMichael, 2003/05/06 01:30 GMT
Oh yes - and I took the liberty of renaming the page for consistency with others like it.

See also: PurpleWiki

addPurpleNumbers --MikeMell, 2003/05/07 20:59 GMT
I see on the Issue Tracker that Safari, my favorite browser, doesn't retain Zope cookies. That explains my lack of cookies. Now I'm back on IE.

Thanks for the placeholder and inserting the call in all the render methods. I finally have access to our Zope server. I've got the new code out of cvs and onto our server and am just getting started.

I plan on doing some of the processing in prerender and some in addPurpleNumbers. Not sure where the best place is to hook into prerendering for all render methods. Any suggestions?

addPurpleNumbers --SimonMichael, 2003/05/07 21:15 GMT
No.. each render method tries to be self-contained. I would just deal with one render method for now, eg the main stxprelink..etc one. addPurpleNumbers appears in the rst.. method due to my copy & paste.

I think I missed something about nids: they are supposed to remain attached to certain paragraphs once assigned, and presumably for this reason PurpleWiki includes them in the source, so you can cut and paste them along with the paragraph. I'm confused - are the nid numbers in PurpleWiki purely user-assigned ?

I was not thinking in terms of having purple numbers embedded in the source text. IMHO that adds too much burden for general-purpose wikis.

PS --SimonMichael, 2003/05/07 21:22 GMT
on the other hand, markup rules continue to evolve and maybe this will become more natural. Maybe RestructuredText will develop a graceful purple numbers notation.

Also, right now they can be added manually using standard HTML anchors. Say you add a tricky CSS rule to StyleSheet? to make anchors visible and purple - are we done ?

How I think these things will work --MikeMell, 2003/05/07 22:00 GMT
PurpleWiki numbers are never user-assigned. Only computer assigned.

Yes, nid's are supposed to remain attached to the paragraph they first were attached to. That is the heart of the purple number system - tracking paragraphs whereever they go.

Here is my understanding of the PurpleWiki functionality applied to ZWiki:

It's my understanding that we use markers, e.g. [NID 2]?, instead of actual html in the pre-rendered text so as to hide the html from users of the site when they edit a page. These markers are sort of structured text for computers. [094]?

We need to add the NID's in the pre-render phase, because once a datum has been marked with a NID, that NID must remain immutable. [095]?

nid marker --MikeMell, 2003/05/07 22:04 GMT
since the square brackets [] already have significance in ZWiki, we may need to pick a different delimiter. I'll code so that the delimiter is held in a variable. [096]?

don't show NID's when editing --SimonMichael, 2003/05/07 22:54 GMT
Since users aren't supposed to choose or change NIDs? and they only get in the way when editing, the ideal would be not to show them. When saving, I suppose the wiki could do some sort of match up against the original text to replace the NIDS in the right place (or assign new ones if it can't). [097]?

Matching changes --MikeMell, 2003/05/07 23:10 GMT
The match up of original to new text would get hairy fast. The NID targets paragraphs and the contents of the paragraph may change. We would need inclredible algorithms to match an original with a changed paragraph. [098]?

I don't see how we can not show them in raw text edit mode. We can't strip them out for the edit, that defeats the purpose - by losing track of the paragraph - as much as never inserting them until display time. [099]?

SM mocks up some NIDs? to see how it looks <0100>

Showing NIDs? while editing --EugeneEricKim, 2003/05/08 00:54 GMT
Showing NIDs? while editing is not ideal, but we decided it was the simplest way to do it. As Mike notes, last_nid does not have to be shown; it could be stored in the database instead. This is our eventual intention in PurpleWiki.

As a side note, I think that the Wiki's dependence on the browser's text editing widget is an annoying one, but I think there's a reasonable workaround. If Wikis supported a standard XML vocabulary as well as an XML-RPC or RESTish? interface (I know one of these exist), users could edit Wiki content using the WYSIWYG XML editor of their choice. These XML editors could hide the NIDs?, which would most likely be implemented as XML attributes, from the user.

text editing options --DeanGoodmanson, 2003/05/08 02:43 GMT

>> As a side note, I think that the Wiki's dependence on the browser's text editing widget is an annoying on

ZWiki has built in support for Zope's ExternalEditor tool. (The pencil icon) I'll leave the XML section to others to answer.

can't compile the re 0.348 --MikeMell 2003/05/09 00:37 GMT
I've built much of the functionality to do the Purple Number processes locally. I'm ready to plug them into the ZWikipage?.py file. First I grabbed the CVS rev 0.348 created for this purpose by Simon. I renamed the existing ZWikiPage.pyc (the compiled file) so that it is effectivley hidden. I start and stop the Zope server and hit a previously working Wiki page. I get an error message saying

"Site Error An error was encountered while publishing this resource. Resource not found Sorry, the requested resource does not exist. Check the URL and try again. Resource: ZWikiPage instance at 9498500"

and no new compiled ZWikiPage.pyc file.

This looks to me like the new file, straight out of cvs, won't compile.

When I try on the command line "python ./", I get the message "python: can't open file ./ On previous such tests, the message has been that the DateTime? module can't load, and this while being called as the zope user.

hmph! suggestions?

can't compile the re 0.348 --simon, 2003/05/09 01:19 GMT
You don't need to worry about .pyc files; they'll be regenerated as needed. That kind of error indicates a problem with product initialization; look in Control_Panel -> Products -> ZWiki or your EventLog for a traceback.

Prototype Enabled
MikeMell 2003/05/09 23:17 GMT
Simon, thanks for the tip to look in the control panel. As you may now have guessed, I'm a Zope newbie.

I'm happy to say that I have a prototype working here: email me if you'd like the user/pass

Currently it does not add NIDs? to an element if that element is contained within an element that does have a NID. Not sure how I should handle this, so I'm leaving it alone for now.

Next issues:

Whoops --Square One Again --MikeMell 2003/05/10 01:13 GMT
Besides the Next Issues outlined in the previous post, there is yet another issue: I don't really have a prototype.

I originally planned on tweaking the page text as it looks in the edit view --simple structured text. I couldn't find the hook to do that, so I settled for tweaking the page text after it had been converted to html. This is what I said was "working". Now I realize that this is entirely unacceptable. The NID markers must be embedded and saved in the structured text.

So, though much the wiser, I'm really back at square one. I need to know at what point I can add the NIDs? to the text and save that text to the DB. Seems to me that I need to do this right up front when the page is created, immediatly after the POST and whenever comments are added, again, immediately after the POST.

I'm growing concerned that I won't make the May 15 deadline I have promised.

progress update --MikeMell 2003/05/10 18:41 GMT
All right, I realized that the previous work (pre square one again) was valid for the rendering phase. I am successfully rendering the NID into html.

This leaves two issues

The site-wide NID, though desirable, isn't required for May 15. This leaves me with one big hurdle - getting the NID stored in the data . . .

Need Hook to edit page content for ZWikiAndPurpleNumbers? --Simon Michael, 2003/05/12 20:41 GMT
cc'd from GeneralDiscussion for context:
> Writing a module for ZWikiAndPurpleNumbers? is a fairly straightforward
> task. One key part of the task is to embed the purple numbers in the page
> text, but this is giving me trouble. (See the discussion on
> ZWikiAndPurpleNumbers? for why embedding is necessary.)
> There seem to be only three cases which change the text of a page:
> o when the page is created
> o when a comment is added
> o when the page is edited
> In each case, the entire POSTed? text needs to be scanned for purple
> numbers, adding them where necessary.
> I'm a Zope newbie and have not been able to find where I could edit the
> POSTed? text before it is stored. Can any one point me to the module/method
> where I can add my hook? Thanks.

... --SimonMichael, 2003/05/12 21:30 GMT
Hi Mike - sorry I don't fully understand where you're at and the demo link is down. Maybe post your code changes so far (indented after a paragraph ending in ::). For sitewide storage I would just set an attribute on the folder. (If you want it visible in the ZMI a property should be defined. _upgradeSubscribers() is one place where folder properties are added.) But, think about issues with concurrent users. 1. What if someone reads the last id value just as another thread is about to change it. 2. Concurrent writes to the folder will cause zope to see a conflict error and retry - could limit scalability if there is heavy simultaneous editing going on. Not too much of a worry at this point.

Update --MikeMell 2003/05/14 00:29 GMT
The Node ID I understand the concurrency problem. I thought there were Zope methods to handle this.

A Zope friend has suggested that I create a WikiFolder? class to hold and manage the node id. The WikiFolder? class would sub class Zope folders? Did I understand this correctly? I'm not really sure how to go about creating a WikiFolder? class. It is necessary?

All I want to do is have a counter variable available and persistent (even when Zope is restarted, or the machine goes down, etc) and lockable (for concurrency).

**How do I do it?

The Add Purple Number Issue I'm happy to say that I finally discovered (actually someone had to point it out to me) that create(), edit() and comment() are the hooks I need to do addPurpleNumbers at the correct time. So this issue is finished, unless some surprises show up.

Re: Purple Numbers, ZWiki, Zope --Simon Michael, 2003/05/14 16:28 GMT
cc'ing for wiki readers.

Simon Michael <> writes:
>> The last major peice is to get this persistent ID straightened out.
> Hi Mike, thanks for the code, I will look as soon as I get the chance.
> You want the last ID to be wiki-wide, right ? So just save it as a folder
> attribute. It will automatically be persistent. Eg::
> class ZWikiPage...
> def setLastPurpleId(self, id):
> self.folder().last_purple_id = id
> def getLastPurpleId(self, id):
> return self.folder().last_purple_id
> A _properties entry is optional and only needed if you want it accessible
> to users in the ZMI.
> I'm not sure what is the general way to lock this for concurrent write
> access, I'd like to know. I'd ask on #zope or the zope list to find out.
>> I think that Zope manages page edits so that two people can't edit the
>> same page at the same time and I think this gives Purple immunity from
>> duplicate IDs?. Am I right?
> You're right, zwiki generally doesn't allow one user to save over
> another's changes made at the same time, and this might take care of the
> issue. Either way I would not worry about it for now (YAGNI).

Success! --MikeMell 2003/05/16 17:40 GMT
I'm amazed myself to say that ZWikiPurple? is working as desired and was completed on time.

There is a little clean up I want to do and one Kludge that needs resolution and then I will forward the ZWikiPurple? module and a diff of ZWikiPage to Simon (if that's the right way to contribute).

You can see it in action at though this url is likely to change soon.

The Kludge

The kludge relates to Simon's suggestion in the previous comment:

> def setLastPurpleId(self, id):
> self.folder().last_purple_id = id

I'm initializing the folder().last_purple_id in the ZWikiPurple? module. It tests if last_purple _id exists and initializes if not. This is bad form. the variable should be initialzed when the folder is created, not each time we need to add Purple to a page.

I'll go poking around for the folder creation method next week.

Thanks for all the assistance from JohnG?, Simon and Rob.

Success! --SimonMichael, 2003/05/18 00:02 GMT
Congrats Mike! Very important: I hope next you'll make them numbers, and purple.. for that PurpleNumbers je-ne-sais-quoi :)

I'll be interested to see how this works out in practice.

Actually it is current Zwiki style to initialize things just in time both on pages and the folder.. zwiki pages are intended to work in any zope folderish container, not requiring a special folder type (the Wiki Folder in CMF will probably be dropped).

ImplicitRemoteWikiLinks --DeanGoodmanson, 2003/06/12 18:55 GMT
Would ImplicitRemoteWikiLinks (feature RFC) help, or hinder Purple Numbers? I'd like to be able to say "See ZwikiPurpleNumbers?:#5 " to reference that page, paragraph 5, without having to add a remote wiki link or build a URL. If you have other comments regarding the syntax for ImplicitRemoteWikiLinks please add them there or GeneralDiscussion.

Also, I think is down.

Re: ImplicitRemoteWikiLinks --MikeMell 2003/06/12 21:44 GMT
My implementation of PurpleNumbers is in two phases

  1. when text is submitted, add a unique node id to the end of each paragraph
  2. when the page is rendered or prerendered, convert each node id to an html anchor link

I don't think ImplicitRemoteWikiLinks would affect this system for better or worse. If I understand the intention behind ImplicitRemoteWikiLinks, the purple numbers maybe all you need.

The one caveat to using purple numbers is that the node id's must be embedded in the page content. Some may object to the clutter.

See for a working implementation.


Release --MikeMell, 2003/06/17 02:17 GMT reply
The ZWikiPurple? module is ready for release. How do I go about doing that? There is one new file, and a few small changes required to {nid 549}

... --EugeneEricKim, 2003/07/14 20:51 GMT reply
Any possibility that Mike's work will make it into the next release of ZWiki? A few people have been asking about it. {nid 550}

... --SimonMichael, 2003/07/15 20:12 GMT reply
Just took another look to see what this does - nice and simple. This will be a new page type, am I right ? Mike, do you want to upload the diff here (see the edit form) so I can fit it in with the new page types ? {nid 551}

Diff of ZWikiPage and new ZWikiPurple? module --MikeMell, 2003/07/16 17:32 GMT reply
Following is the diff of the live Planetwork against Revision 0.347 in CVS. To implement Purple Numbers, you also need the ZWikiPurple?.py module which comes after the diff. If you feel the ZWikiPurple? module should be integrated with ZWikiPage, I'll be happy to do that. {nid 553}:

 (I've removed old diffs and Purple module from this location. --Mike)     {nid 554}

Python code in a comment makes big problem (PurpleNumbers) --Simon Michael, 2003/07/17 01:02 GMT reply
Hi Mike - your patch turns on purple numbers everywhere, all the time. That won't work I'm afraid, most people don't want these. {nid 556}

I was thinking in terms of a separate page type for purple lovers to begin with. Or a whole parallel set of page types, but ideally not as I'm trying to simplify these. {nid 557}

Or we could build it in everywhere as you've done but make it depend on a use_purple property. This doesn't help code clarity much. I can't think of anything else right now though, unless we come up with a better design for rendering system. {nid 558}

purple numbers everywhere --MikeMell, 2003/07/17 02:12 GMT reply
I expect that if a web master wants purple numbers, then s/he will want them on all pages of the site. There is an easy switch in ZWikiPurple?.py to toggle adding the nids and another switch for displaying the purple numbers {nid 559}:

 addPurpleNumbersToggle = 1 # 0|1 turn off|on Purple Number embedding and display for all wiki pages --
 displayPurpleNumbersToggle = 1 # 0|1 turn off|on Purple Number display. obey for embedding nid's     {nid 560}

I suggest that you ship ZWiki with both of these turned off. If a user wants to turn them on, that is simple enough. {nid 561}

I think it a bit messy that each page type must call the ZWikiPurple? module (t = displayPurpleNumbers(t)) regardless of the purple toggle state. Yet it makes sense to put the toggle state in the ZWikiPurple? module: people that are not interested in purple are saved from even seeing the preference. {nid 562}

use folder Property to toggle --BillSeitz, 2003/07/17 14:10 GMT reply
because people can be running different spaces with very different purposes (even if they're not running a farm). {nid 563}

And you get the benefits of acquisition this way, too, right? So you could set it at a top-level folder as a default value for all its children. {nid 564}

use folder Property to toggle --DeanGoodmanson, 2003/07/17 14:32 GMT reply
PurpleNumberDisplay? property: +1 {nid 565}

I would also suggest a Badge to set this on a wiki page property similar to the DeleteMe. Badge PurpleNumbers = Creates Purple numbers property:value=0n, RemovePurpleNumbers = turns property "off" (caveat: cleanup) {nid 566}

But this first-line syntax is a bit mystical, a checkbox onthe edit page would probably suffice, with a default value set via folder property. {nid 567}

PurpleNumbers page created --DeanGoodmanson, 2003/07/17 14:44 GMT reply
New Zwiki Resource TestPage (primarily as I keep typing Purp.. in the URL..) at PurpleNumbers. {nid 568}

Please add a Remote wiki link if it would help, possibley an "implementation status" blurb or link, and any other relevant discussion channels. {nid 569}

use folder Property to toggle --MikeMell, 2003/07/17 17:24 GMT reply
After shutting down last night I remembered Bill's request weeks ago for folder properties and how that would answer Simon's concerns. {nid 570}

With Bill's latest encouragement here, I've altered the code to use folder properties. The code posted above (diff and module) now contain the latest version using folder properties. {nid 571}

I've tested it on the Planetwork server. Everything seems to work. However, I don't understand how I can change a folder property in the ZMI. I can't even find the property in the ZMI! {nid 572}

setting folder Property --BillSeitz, 2003/07/17 17:54 GMT reply
just open a folder in ZMI, hit the Properties tab, then use the Add form to set a name and value (and value type). {nid 573}

(Hopefully your code handles the lack of a property without crashing) {nid 574}

setting folder Property --MikeMell, 2003/07/17 18:20 GMT reply
The properties are set in the ZWikiPurple? module if they are not already set using a try statement. See the __init__ method of the ZWikiPurple? class in the code above. This method of setting properties was recommended by either Simon or Rob Miller, an advisor to Planetwork on Zope matters. I prefer to let the code generate the properties. It seems needless work to make site admins set a property just to turn on the thing. {nid 575}

Following your instructions "just open a folder in ZMI, hit the . . ." does not reveal the properties created this way. {nid 576}

Unique site-wide nid --MikeMell, 2003/07/17 18:58 GMT reply
I didn't realize wiki's could have multiple folders. This means that the is unique to the folder only, not to the entire wiki installation. Purple numbers should really be unique to an entire installation. In the ideal world a nid is unique to the world, but we're not there yet. {nid 577}

Looks like we need a new container for the lastPurpleId which is site-wide. Any suggestion? {nid 578}

request --Simon Michael, 2003/07/17 21:10 GMT reply

> folder properties. The code posted above (diff and module) now contain
> the latest version using folder properties. {nid 580}

Thanks Mike. Hey, for efficiency I think it might be better to upload these as files instead of pasting on the wiki page - they're kind of large and that way we won't have to keep messing with the indentation. and would be ideal. {nid 581}

Also, can you generate the patch against the latest code - CVS, or at least 0.20 ? I spent too much time fiddling around with it yesterday. {nid 582}

setting folder Property --Simon Michael, 2003/07/17 21:16 GMT reply

> The properties are set in the ZWikiPurple? module if they are not
> already set using a try statement. See the __init__ method of the
> ZWikiPurple? class in the code above. This method of setting properties {nid 584}

Small clarification - if I read aright it looks like you're just setting a folder attribute, which won't appear in the ZMI. In the zope world we call it a "property" if you also add some metadata to the folder's _properties attribute, making it visible in the ZMI. {nid 585}

Unique site-wide nid --Simon Michael, 2003/07/17 21:19 GMT reply

> I didn't realize wiki's could have multiple folders. This means that {nid 587}

They can't. One wiki = one folder AFAIK. Are you thinking of a SubWiki ? That's a separate folder/separate wiki. {nid 588}

Unique site-wide nid --SimonMichael, 2003/07/20 05:52 GMT reply

> Looks like we need a new container for the lastPurpleId which is site-wide. Any suggestion? {nid 589}

I just understood this bit. Well, I guess instead of storing the attribute on the current folder, use zope's root folder (getPhysicalRoot() ?). {nid 590}

request --SimonMichael, 2003/07/20 06:05 GMT reply
I think the patch above is wrong, but no matter. I have the gist of it now. I'm pondering the integration with zwiki a bit more. {nid 591}

I spent some more time over on the planetwork/purple numbers/bootstrap sites reviewing the purple number implementations, the usefulness of the feature, etc. Got some more insight from the mailing list. Good and interesting work being done over there, zwiki folk should check it out. Exploring how to work together so as to boost our collective IQ. {nid 592}

Unique site-wide nid --MikeMell, 2003/07/20 18:11 GMT reply

> getPhysicalRoot() {nid 593}

cool. that works. {nid 594}

another prototype --SimonMichael, 2003/07/21 04:01 GMT reply
Mike - if I understood your code, I think it renders the purple numbers before the text formatting rules are applied. This is a problem for non-STX modes since they don't allow HTML to pass through unscathed. Inspired by your prototype, I've made another stab at this. I add the purple numbers markup after the conversion to HTML. As usual I used a dumb regexp approach, which may be ok since text formatters should generate reasonably well-formed HTML. See It's using your addPurpleNumbers right now, though I think this will benefit from some tweaking and probably separating to handle the different formatting rules. ( {nid 595}

This is hooked in to the render methods, and _setText (see It activates in the presence of a true use_purple_numbers property, which can be on the page, folder, or a parent folder. I've enabled it on this page for testing (and on TestPage, if you really want to go wild). {nid 596}

Let's see how the page looks after this comment. Looking forward to your feedback.. {nid 597}

yeow --SimonMichael, 2003/07/21 04:30 GMT reply
How did I manage to post that four times. {nid 598}

I've made it display the nids and use base 10, so I can see what's going on. Glitches: some nids get eaten by the message formatting code, and some don't get formatted. {nid 599}

made it skip the message headers --SimonMichael, 2003/07/21 06:00 GMT reply
and ignore differing indentation within a STX paragraph. {nid 614}

another prototype --MikeMell, 2003/07/21 15:29 GMT reply
I've integrated the required changes into the latest version of ZWikiPage in cvs. If you want that for development here, let me know. {nid 1188}

I've begun implementing folder properties by inheriting OSF.PropertyManager? into Purple. I'm not sure this is the correct method. The PropertyManager? docstring states {nid 1189}:

 An object which wants to have properties should inherit from PropertyManager. {nid 1190}

The properties in question should be attached to a folder not Purple itself. Still looking into the issue. {nid 1191}

I'm going to be distracted by another project for a few days. Hope to get back to this asap. {nid 1192}

weird formatting of last comment --MikeMell, 2003/07/21 15:32 GMT reply
not sure why the second line of my previous comment is bolded. Something to do with nid following the code marker (::)? {nid 1193}

issues --SimonMichael, 2003/07/21 20:37 GMT reply
Hi Mike - thanks. Is your cvs accessible ? {nid 1194}

When you get a chance to review my latest, let me know what you think. I will check in to CVSRepository (browse) but want to do a little more cleanup first. {nid 1195}

You don't need to do all that with PropertyManager. And you're right, we can do away with the ZWikiPurple class. We can just manipulate the folder directly at runtime. {nid 1196}

nids after a structured text :: quote break the formatting of that and the following paragraph. We can solve this by making addPurpleNumbersToSTX smarter I think. {nid 1197}

More difficult will be making this work with RestructuredText, I think. It's more strict and I think it will be hard or impossible to sneak nids through it without breaking formatting. That it mostly works with STX is luck and trickery and partly, STX's simple, flexible design. Your way (converting nids to HTML before formatting) has the problem that HTML gets quoted during formatting. My way (converting nids to HTML after formatting) requires that nids be smuggled through the formatting, without disturbing it or being disturbed by it. I feel as if we need an invisible nid placeholder that stays put through the formatting. {nid 1198}

issues --SimonMichael, 2003/07/21 20:43 GMT reply
And not just through the formatting, but other stages like DTML evaluation, fit test parsing etc. If we store the nids in the text, it seems we want to remove them early, remember where they were, do all other rendering, and insert nid targets & links in the right places at the end. {nid 1199}

issues --SimonMichael, 2003/07/21 21:06 GMT reply
Maybe what it boils down to is this: if you embed nids in your wiki-markup text, you've got to treat them as part of the text and fit them within the markup rules. So for example with STX's :: operator, it must be ::

  some text { nid 1}::
and not simply::
  some text:: { nid 1}
{nid 1213}

checked in --SimonMichael, 2003/07/21 22:27 GMT reply
Oops, I'm not following ReleaseProcess.. but this seems to be a low-risk addition now. Note viewcvs is 24 hours out of date. {nid 1214}

I fixed the handling of ::, except it still inserts nids within the quoted region, which don't get rendered. {nid 1215}

Plenty more we can do, but what we have working here at least will be in zwiki 0.21. Thanks, you all! {nid 1216}

page name --SimonMichael, 2003/07/21 22:28 GMT reply
This page should probably merge back with PurpleNumbers. Any objections ? {nid 1217}

ZWikiPage diff --MikeMell, 2003/07/22 01:23 GMT reply
OK, I realize you're moving the calls to displayPurpleNumbers later in the ZWikiPage processing, but, here is the diff from ZWikiPage 0.382. Sorry, I don't have a cvs server. How do I post files to the ZWiki? {nid 1218}

Oh, boy, this is going to be whacked. As soon as I post the diff, it will have nids! {nid 1219}::

( posting the file to the page, removing it from here. --Mike) {nid 1252}

nids not processed --MikeMell , 2003/07/22 01:25 GMT reply
hey! the nids in my diff didn't get processed. And actually, there should not be any nids on those lines. nids only come aftera paragraph or list item, not after every line break in the file. {nid 1238}

ZWikiPage diff --Simon Michael, 2003/07/22 01:30 GMT reply

> Sorry, I don't have a cvs server. {nid 1240}

Ok. I was confused by your "I've uploaded the latest to cvs" (and still am :). {nid 1241}

> How do I post files to the ZWiki? {nid 1242}

Click edit, use the file upload widget, click save. {nid 1243}

> Oh, boy, this is going to be whacked. As soon as I post the diff, it
> will have nids!:: {nid 1244}

Yes, note you can work around it for now by using pre tags (and no blank lines) instead of :: quoting. {nid 1245}

Bye for now -SM {nid 1246}

issues --MikeMell, 2003/07/22 01:42 GMT reply

> if you embed nids in your wiki-markup text, you've got
> to treat them as part of the text and fit them within the markup rules {nid 1247}

It's really important to not burden a page author with nids. Purple Number adoption won't happen if it demands work by authors. We can not expect them to create or move nids to workaround issues like { nid 1} :: {nid 1248}

no cvs server --MikeMell, 2003/07/22 01:44 GMT reply

>> I've integrated the required changes into the latest version of ZWikiPage in cvs {nid 1249}

> Ok. I was confused by your "I've uploaded the
> latest to cvs" (and still am :) {nid 1250}

I meant the latest version of ZWikiPage residing on your cvs server. {nid 1251}

File uploads --MikeMell , 2003/07/22 02:00 GMT reply
I've uploaded and diff_ZWikiPage.0.382_for_Purple.txt. The diff applies to the file in the ZWiki sourceforge cvs. is the module I've been concocting, renamed to Purple as requested. {nid 1255}

Now that you're incorporating your own ideas on this project, I'd like to you grab these new files and use them for starters and build from them. The now uses site-wide unique nids and has the beginnings of an attempt at folder properties. (I've deleted the bits about OSF.PropertyManager?, but left in some of the code that attempts to retrieve the folder properties.) Also, the intra-module documentation is more polished than in previous verisons. {nid 1256}

If you want to delete the Purple class (was ZWikiPurple?), that's fine. It may have been there only to avoid checking for the existence of the site-wide nid variable more than one time per page. {nid 1257} {nid 1253}

diff_ZWikiPage.0.382_for_Purple.txt {nid 1254}

PN are so cool! --FlorianKonnertz, 2003/07/23 21:14 GMT reply
I upgraded NooWiki yesterday to 0.20cvs and i am glad to be able to use PurpleNumbers now. :) To activate them adding the use_purple_numbers property and running upgradeAll was not enough, i had to modify it so that all pages were edited. Here are my changes ( line 2654ff - thx to Simon) {nid 1260}:

          for p in self.pages():
                n = n + 1
                if pre_render:
                if upgrade_messages:
                DLOG('page #%d %s'%(n,
                if n % 10 == 0:
                pass {nid 1261}

The try/except is because one page caused an recursion error, no idea why. The append... calls the edit method, so all pages are touched once. {nid 1262}

I hope to find the time to play aroung with PN a little bit these days, so i probably will discuss further. One issue for now: My RemoteWikiLinks fail because of the nid entries after the keyword in the same line (?) I guess you already recognized that!? Ideas? {nid 1263}

RemoteWikiLinks prob patch --FlorianKonnertz, 2003/07/23 21:41 GMT reply
Add this line around line 261 ( {nid 1264}:

  if re.compile(remotewikiurl).search(text[i]): continue # this line contains a RemoteWikiURL {nid 1265}

and at the top (line 3) {nid 1266}:

  from Regexps import fromlineexpr, nidexpr, remotewikiurl {nid 1267}

Of course all pages that already got a nid in the RWurl? line have to be edited resp. upgraded again to make this change take effect. {nid 1268}

Cheers, FloK {nid 1269}

PN fail on every new indention level of bullet lists --FlorianKonnertz, 2003/07/24 04:47 GMT reply
Rendering of PN fails also on every new indention level of bullet lists. See NooWiki:TableOfContents for an example. - Just testing here: {nid 1270}

URLs? break because of ; --FlorianKonnertz, 2003/07/25 08:34 GMT reply
In lines with an URL at the end there's a ; before the nid (set by the PN module?) - some URLs? break because of this... - FloK {nid 1274}

... --FlorianKonnertz, 2003/07/25 08:38 GMT reply
test if also on this site: {nid 1275}

repopulate wikifarm method needed --FlorianKonnertz, 2003/07/31 11:43 GMT reply
Meanwhile i have a bit of a mess of PNs? in my ZwikiFarm?. At the beginning the main wiki was populated, then i migrated the SubWiki-s, where the numbers didn't appear at the beinning. So i had to re-run upgradAll and got them. And now they have been starting again at zero. - So i would like to delete them all and repopulate the whole thing. Have you already thought of making a script or method for this? Some people maybe want to get rid of them again one day (on some part of the site) - (or did i miss it??) - flo {nid 1278}

disabling use_purple_numbers leaves nid's in the text --AndrewDalgleish?, Sun, 24 Aug 2003 06:43:14 +0000 reply
until you hand edit to remove them. {nid 1793}

ZWIKI Bug? -- Mon, 01 Sep 2003 15:23:43 -0700 reply
the above link in line #1280 ist linked as which does not work. {nid 1794}

control display of PN by user per cookie --FlorianKonnertz, Wed, 03 Sep 2003 09:38:32 -0700 reply
I want the user to be able to switch PNs? off for easier readability, so i made it controlled by UserOptions? per cookie. The downside is that i have to give the REQUEST to renderPurpleNumbersIn {nid 1795}:

  def renderPurpleNumbersIn(self, text, REQUEST=None):
              if (REQUEST.has_key('zwiki_showpurplenumbers') and REQUEST.get('zwiki_showpurplenumbers')=="1" ):
            show_purplenumbers = 1
            show_purplenumbers = 0 {nid 1796}

Then the flag is set and given to {nid 1797}:

    def renderPurpleLink(self, purpleNumberString, show_purplenumbers=0):
        if show_purplenumbers == 1:
            return '&nbsp;&nbsp;<a href="%s#nid%s" class="nid" style="font-family:Helvetica,Arial,sans-serif;font-weight:bold;font-size:x-small;text-decoration:none;color:#DDDDDD">(%s)</a>'\
               % (self.page_url(),purpleNumberString,purpleNumberString) {nid 1798}

            return '' {nid 1799}

It works well, but maybe you have an idea to improve it!? {nid 1800}

control display of PN by user per cookie --Simon Michael, Thu, 11 Sep 2003 16:16:47 -0700 reply
I think that's a nice option. People may forget and be confused by the numbers when editing of course. {nid 1801}

ZWIKI Bug? -- Thu, 11 Sep 2003 18:59:27 -0700 reply
works now. Has that been fixed or can you reproduce it? {nid 1802}

better editform helptext (was: control display of PN by user per cookie) --FlorianKonnertz, Fri, 12 Sep 2003 00:54:52 -0700 reply
Hmmm.. ok, maybe a little warning at the top of editform could help, i gonna add this asap. {nid 1803}

Ok, maybe an addition to the help text (balloon help) makes sense in general. {nid 1804}

ZWIKI Bug? -- Sat, 13 Sep 2003 23:15:37 -0700 reply
The problem still occured. This time with two %A0 appended to the URL. It's fixed now. I added a space and then a period after the URL. I think having spaces and then the open curly braket of the purple number was somehow causing ZWiki to include the spaces in what it recognized as an URL. Is this a bug in ZWiki? {nid 1805}