Forum OpenACS Q&A: OpenACS Wiki

Should content be in the content repository?  This would give automatic journalling of Wiki content, though given how people use Wiki's that could generate lots of revisions!  Still ... it seems journalling would be useful.

It doesn't require any datamodel changes for ETP, does it?

I see a lot more value in a Wiki that you can restrict to, say, registered users.

For example, on a corporate Intranet, make a Wiki that can only be edited by a department, but other people can look at.

Or for http://www.safe4all.org, we'll have a resource guide which is edited by volunteers.

I can also imagine it being good for collaborative documentation.

Since we keep all the versions, I think this is an improvement on the traditional Wiki. If you want a wide open Wiki, then just set permissions to be open to anyone.

I thought about using wiki's efortless linking feature in my Cookbook application (on which I have done some real work, and yes, it uses the CR). But I'm having second thoughts.

I wanted recipe submitters to be able to easily link to other recipes by knowing just a "short name" (if you will) for the recipe, instead of having to memorize an id. But maybe that's not such a good idea.

To get my cookbook where I want it to be, I need to pick up and finish general-ratings too (anyone knows where that's gone?).

-Roberto

I think ETP-based is the right approach, BTW, and the ETP is already doing CR stuff (though harumph poorly in some regards)

Dave's got a test instance up apparently ...

One page on that doc that got me going in CR is this

https://openacs.org/doc/acs-content-repository/object-model.html

Thanks to DanW for pointing me to it, after that I was able to understand pretty much how CR works.

Here are the comments I sent to davb when I ported wiki to ETP.

Current issues.
* URLs of the with / are not supported in wiki.
* etp::get_pa - modification is not clean. See comments in file.
* the interface doesn't flow. Maybe its because I am used to the old system
* I have no idea what subtopics, extlinks and symlinks are.
* the wiki templates are very rudimentary.

Pluses
* ETP design is very good. I have never worked with the openacs 4.x series and a port this far in
is a testament to the design
* permissioning. I always had granular permissions in mind for wiki. Now they come built in!
* versioning and content management - again very nice design of etp and the content system. So much code got delegated from the actual wiki app.

Personally it is VERY tempting to write things from scratch. (maybe its a psychological thing) and I do it quite frequently.

However with ETP Wiki I put my desire for a complete re-write on hold and was shocked by the time it took to port. The fundamentals of ETP are quite sound. I would not recomend another port. Especially since davb is handling the issues.

Some interesting things would be:

1) Wiki Input Widget - can be used in various parts of the site e.g bboard input, wiki syntax is way easier to learn, way easier to type and way easier to read even in raw wiki form.  I designed the original wiki to encourage better documentation at my previous office. I was pleasantly surprised.

2) Diffs rather then complete documents for various revisions - Both the original wiki and current ETP wiki store complete document revisions. They also display complete document revisions. It is HARD to tell what has changed, especially for large documents. There are two possibilities.

a) Store diffs in the cr.
b) DISPLAY diffs when browsing revisions. This allows the use of command line tools (maybe there is a tcl api for generating diffs).

I would go with b) - easier to integrate with existing tools, and doesnt bastardize the CR model.

3)Support for images and multimedia content - currently etp handles images by allowing you to place a link to an image. Upload of the image is your concern. A better design would step you through and collect this information for upload.

Regards,
Hafeez

It seems to me that everyone who understand the toolkit better than I do recommends doing it with Dave's code (on ETP). I think it would be easier, however, to just go with Jamie's adapation of Hafeez's code.

I'm not sure how much work it will be to get Dave's code working like a Wiki should, but it may be pretty simple. He's already done most of the work. It does need automatic link generation, and work on the interface. Probably the biggest advantage to working on Dave's code is that he'll probably help you or I out with questions. 😊

I'm putting this on hold for a little while. I still need a Wiki pretty soon, but I may not be able to work on it for a week or two.

Its half finished. The formatting works, but the linking to other pages using wiki-names does not. There is a way to register a callback tcl proc to generate the links and I haven't figured out how to make it work. Otherwise it is just the plain old tcl wiki code.

I can send you a copy if you would like.