The new Wiki software looks promising. It certainly is fast. No doubt a lot of work went into it. Now that the JOS Wiki on www.metamech.com has been locked, Wiki authors are forced to cope with problems in the sfWiki software. This article may help authors to migrate from the "old" Wiki to the "new".
Here is a partial list of problems:
- The sfWiki software provides an HTML form to edit an article. Its text area field does not seem to word-wrap appropriately.
- Pressing the Back button after using the preview page is like an undo; unlike the "old" JOS Wiki it reverts to the original article.
- In order to insert a tab character in a text area, it is necessary to use copy/paste. The tab key does not enter a tab character, but moves focus to the next component (a preview button).
- Should the word "sfWiki" link automatically. It is not exactly a Wiki name. Instead it requires the percent sign (%) before and after the article name. It wasn't linked in the "old" Wiki software either.
- By the way, how to you enter a percent sign (%) when you do not want to indicate a link with a percent sign (%)?
- It is not obvious that an article name must be unique in all forums. I tried -- unsuccessfully -- to link a page in one forum to an article in another.
- Can I reuse an article name in another forum? No, but it is not obvious. Since articles seem to be unique across all forums, articles should be displayed regardless of forum. If I create an article with the same name in another forum, will it overwrite without warning? Yes, it will. I lost my personal page just like that.
- Multiple links on a line do not work quite right. For more information, see also articles A B C D E F G H I J K L M N O P Q R S T U V W X Y and Z.
- An article should never contain a link to itself. Even the "old" Wiki software didn't get this one right.
- Does the <nolink> tag apply to one word? Or does it apply to the rest of the article? Is </nolink> required?
Some critical HTML tags are no longer supported.
- <A NAME="name">A name is used in an HREF.
- <A HREF="#name">An HREF uses a name.
- <FONT SIZE="-1">How do I change the size of a font?</FONT>
- <FONT COLOR="red">How do I change the color of a font?</FONT>
- <P>Mark the beginning and end of a paragraph with a tag.</P>
- <A HREF="sfWiki">How do I link to an article in this forum?</A>
- <A HREF="../User/ToddMiller">How do I link to an article in another forum?</A>
- <A HREF="http://cjos.sourceforge.net/redist/">How do I link to another page?</A>
- <A HREF="http://cjos.sourceforge.net/redist/mirror/jos1i/">How do I link to an archive file (.gz, .tgz or .zip) for others to download?</A>
- <HR SIZE="1" WIDTH="50%" NOSHADE>How do I encode a customized horizontal line?
- <IMG align="right" alt="JOS" src="/pics/jos_logo2.gif" border=0>How do I encode an image?
- <APPLET WIDTH="10" HEIGHT="10"></APPLET>How do I encode an applet?
- <APPLET><PARAM NAME="host" VALUE="wiki.jos.org"></APPLET>How do I encode applet parameters?
- <TABLE BORDER="1"><TR><TD BGCOLOR="red">How do I encode an embedded table?</TD></TR></TABLE>
- Iain, do you know how to fix this?
- Whoops. I originally misunderstood what you were saying. I'm not sure what the proper behavior should be, though, since you can continue editing from a preview page.
- Tabs in the edit field appears to be browser-specific (e.g. NS4.7x works), and [three spaces] works as well.
- Hm. Iain?
- This bug was fixed by very slightly limiting what can be placed between % marks and linked. (To letters, numbers, and spaces.)
- see below
- see below
- This has been fixed.
- Why not?
- <nolink> only works on the next word, and as such </nolink> is not necessaary. It's not a 'real' markup in that sense. WikiWord WikiWord.
By the way, thanks for the feedback.
- You don't need HREF tags. WikiLinks are automagically created, and http://jos.org, etc, is autolinked as well.
- You're right, it should be more obvious that names are unique across forums. (Good word, BTW.)
- Editing the same topic name in a different forum will now silently redirect you to the topic in the right forum.
- You could use header tags for different font sizes. If you think there's a good reason for including the FONT tag, let us know on the mailing list.
- P tags are unnecessary. Use a blank line.
- Users.ToddMiller links to the specified web. ToddMiller linking to the wrong web was a bug. (Fixed now.)
- Custom HR line -- see the font size response.
- Incidentally, I think it's helpful to sign your WikiName. :)
Saving preview text: Going back and editing the same text you had entered would require storing the text in the session or repost it in a hidden field. Alternatively, you can create a temporary edit table when they first edit. Then keep changes (every time they hit preview) in that table until the save button is pressed. The save button obviously deletes the temp edit record and writes it to the real wiki database. Have you noticed that your edited text is preserved on the preview page (where you can continue editing it)?
Autolinking sfWiki: Are you saying just autolinking the particular word "sfWiki" or words with that format? As far as I'm aware, sfWiki is not proper WikiName format. And I don't think that sfWiki itself needs special treatment. One of the intents of our stricter formatting is to strongly encourage people to use Wiki markups rather than doing things the "manual" way. There are ways of creating wiki links from the rather unimaginative like ThesfWiki and SfWiki to something a bit better such as SFWikiInfo or AboutsfWiki or InfoOnsfWiki. By forcing you to explore these options, we hope to have you use proper wiki names only and not force pages with non-WikiNames. The full text search feature of the sfWiki makes finding information easy even if its embedded in a page with a slightly non-intuitive WikiName.
Without forum-specific rendering, these pages were once un-readable:
- GilbertHerschberger (22 April 2001)
- When writing reference articles, authors are often required to provide section names. The NAME tag enables someone else to refer to a specific section within a document. Likewise, when writing research articles, it is often necessary to link to a specific section of another page (or article).
- Look at the Portland Pattern Repository. Its wiki software automatically provides section names for each heading and cross-references headings at the top of each article.
- When writing step-by-step procedures, it is often necessary to write multiple paragraphs in a single bullet point. A blank line breaks the bullet point. The paragraph tag should be allowed.
- When creating "diagrams" of operating system architecture, it is often necessary to put tables inside other tables. How is one table embedded into another? How do I control table color? cell color? cell padding? cell spacing? border?
Heh. Forgot about dating. :)
I fixed WebHome, with nothing lost. (Well, the webring code moved to
the index page.) I'll look at the others later, but I suspect they're the same.
- If an article is large enough to require anchors, split it up and create links.
- This is a good point.
- I'm working on a system to allow this.
- Until then, consider using nested lists, instead of blank lines.
- See the response on the mailing list.
- ToddMiller (23 April 2001)
-- GilbertHerschberger (24 April 2001)
- I fixed WebHome, with nothing lost. No, no, you didn't. For example, you'll find that the original WebHome article at http://www.metamech.com/wiki/view/Main/WebHome uses
ALIGN="RIGHT" to place the image on the right side of the page. You're "fix" puts the image on the left side of the page. If that were not enough, links to other articles are not rendered correctly by sfWiki software.
- If an article is large enough to require anchors... An article like this one is a good example of where anchors should be used and creating separate articles is inappropriate. I should be able to link my response to your original comment. That's the purpose of anchor names. It has little or nothing to do with the length of an article.
- Forum-specific rendering has eliminated countless hours of editing on an article-by-article basis. Good job! Should I work on JJOS software? or work on restoring hundreds of wiki articles? I don't have time to do both. I would rather spend my time on JJOS, rather than re-working existing articles. But -- unlike you -- I understand that without those existing articles, people may never find out about the work our members are doing. The work of our volunteers is precious. It must not be squandered on re-working existing articles.
- It is easy enough for a wiki developer to become fantasy-based. It is difficult for a wiki developer to keep up with what markup has already been used on each of our 2800+ existing pages. Teamwork is required to make sure all 2800+ articles are legible. As a developer, a purist viewpoint may be more restrictive than authors want. For these reasons, sfWiki was poor quality software when applied to the JOS Wiki before the implementation of forum-specific rendering. The previous version of sfWiki failed to meet my expecations.
- Does sfWiki lock an article so that changes made by one person won't be mistakenly overwritten by another? I can assure you this feature was supported in the "old" JOS Wiki on
- The sfWiki software does not limit its potential audience by writing only one renderer when, obviously, more than one renderer is possible. Why not make rendering a forum property, making it possible to plug in a renderer on a forum by forum basis? While one renderer can forbid embedded HTML tags, another can allow them. While one renderer supports the original wiki markup from the Portland Pattern Repository, another can support exciting new markups. Plug-in renderers make it possible.
- Very bad rendering would force me to start looking for alternative software, such as QuickiWiki. If I had to build it myself, PersonalWiki would be written in the Java programming language, use the SmartAPI and a servlet-program model. At least, my software would run on a Java-based operating system. As an author, I'd rather not have my articles rendered illegibly.
- ToddMiller (24 April 2001)
- If you believe that the position of the JOS logo is an important part of the information captured in the WebHome topic, I will refuse further discussion with you, as our differences in opinion are too fundamental to be bridged.
- Your comments are on the same page as my originals, and the flow of discussions works just fine as you have it, and as it works on usenet, with quotes.
- Whichever is more important to you, naturally.
- Your insults, combined with your desire to whine but not help, grow tiresome. I try to advance the goals of the Project as I understand them to the best of my ability. Others have made constructive suggestions about how to so do -- unfortunately, after the opening -- and I will work to implement them.
- No. (Neither did the JOS wiki.) Submit a feature request.
- This is an interesting idea, actually. I'll think about it.
- Odd. You refuse to help, and declare, as it it were a threat, your intention to write another Wiki. (Incidentaly, IainS has reserved space at ejip.net to investigate the possibility of hosting JOS Wiki with Java software. Contact him for more information.)
I wholehearted applaud your decision to put all articles imported from the "old" JOS Wiki into the
imported forum. It is the right thing to do. There are many, many benefits to this. First and most important, imported articles are easy to read; they look great! Second, we can move articles from the imported forum to the main forum at our leisure. The forum attribute of an article helps distinguish between an old article and new. Excellent job!
-- GilbertHerschberger (26 April 2001)
- In my opinion the sfWiki software just went from worst to first. It might be the best wiki software on the web. It is fast, easy to install, easy to host. It provides user accounts and forums, full text indexing and search, hubs and nodes. It provides forum-based renderers, which makes it possible for others to import their wiki text into sfWiki with the minimal of muss and fuss. It exceeds my expectations. It provides a concrete mechanism for perfect compatibility with other wiki software. It's a winner.
- I share my opinion with you about what might be wrong with sfWiki for the JOS Project because I want sfWiki software to be the best software possible. I'm sure that's what you want, too. I'm sorry you fault me for this. I have helped you as much as I can. It's ultimately for the good of the project. Your decision to include a forum-specific renderer has saved me countless hours of article-by-article editing. I appreciate that.
- The JOS Wiki software at
www.metamech.com actually "locked" an article and warned when an article was locked by another. As an experience Wiki user, I know this feature well. Someone with less experience might not realize that this feature is really there. This article itself illustrates the need for "locking". Another user overwrote my response without warning. Apparently, they were in the middle of editing when I posted my response.
- ...your desire to whine but not help You selected a programming language for sfWiki. As you know, it is a language that I do not know. My help to you has included far more than writing code.
- You refuse to help, and declare, as it [sic] it were a threat, your intention to write another Wiki. Competition is competition, not a threat. Even if I intended to build yet another Wiki (which I don't), telling you about my intention would be the honorable thing to do. I want to remind you that our implementation of sfWiki software for the JOS Project is a choice. It is the best choice, but not the only choice.
- Let's move on. An honest difference of opinion shouldn't make it impossible for us to work together again. I'll try to be more sensitive in what I say. We should get back to building a Java-based operating system, shouldn't we?
Talk about turnarounds. I may have to quote you on the sfWiki homepages now. :)
I recognize your desire to help, but as with some of our other exchanges, you do so in an a way that can be very abrasive. I look forward, however, to moving on and working with you, and I thank you for your kind consideration of your words in our further discussions; I will endeavour to display further restraint and civility as well.
I look forward to your commentary on NewFormattingRules. I also think it's time to refactor this page (or this page to another) into a list of current problems. (Perhaps migrating requests to sfWikiRequests?) Did you want to do this, or should I?
- ToddMiller (27 April 2001)
My most recent review of the Portland Pattern Repository and QuickiWiki
software reminds me of another feature I'd like to see in sfWiki. Look closely
at the title of an article. See how an extra space is inserted before each
uppercase letter to make the title more legible.
According to The Wiki Way, instead of showing the full text of a link,
it can be rendered like a footnote, using a pair of double brackets as in
- WebHome becomes "Web Home".
- WhosWho becomes "Whos Who".
- WhyNotMultiProcessJVM should become "Why Not Multi Process JVM", right?
- An article title is a link, too. Clicking on a title displays a list similar to sfWiki's "into" link.
[[http://www.jos.org/]] sometext. This should be rendered
[n] sometext where n is a link and displayed as a number,
starting with 1.
-- GilbertHerschberger (5 June 2001)
The Preview feature of the sfWiki software has a problem. I had to write the
full text of the TheWikiWay article twice today. Unfortunately, there are
links, including the edit link, displayed at the top of the Preview page.
Your changes can be lost if you use the current browser window to visit
another page before you press the Save button.
You can either
-- GilbertHerschberger (12 June 2001)
- refresh the preview page to re-display your changes, or
- use a new window to visit other pages.
I'm not sure that this can be prevented; the server never sees the changes you made in preview, so it can't send them back to you. Do you think it would be worthwhile to investigate supressing the standard header?
-_Quinn ( 13 June 2001 )
Content of these pages are owned and copyrighted by the poster.