[Seaside] [BUG] Tutorial 2 report

Jim Benson jb@speed.net
Mon, 27 May 2002 00:58:15 -0700


Avi,

> It would be very cool to see some kind of super-seaside-wiki evolve.  One
> small thing I've considered in this direction is adding a WikiParser to go
> with the standard html parser and sexpr parser.  This would create normal
> Seaside templates (perhaps with a special WikiWordElement?) from
> wiki-formatted text.

Right, you just write a wiki using Seaside. The wiki itself should be pretty
trivial after you get the wiki parser done. It looks to me that the Swiki
effort got mixed up by trying not to be Smalltalk. When I evaluated it for a
new project, it did not appear to be a platform that I would be comfortable
developing on, as there were quite a few changes I would have to make to the
Swiki environment itself.

For example the whole navigation thing. I edit a page, start navigation, and
my history still has the edit page (unexpired) in there. As my friend told
me, "That's just not right". In addition, there was no "preview the page
before posting" function, which combined by the elementary email
notification system can fill up your mailbox real quick. You want to be able
to use the Seaside continuations and #isolate: features to handle the
editing correctly, i.e. the edit/preview cycle needs to happen, and the
browser should expire those pages when the cycle is over.

The wiki idea is pretty wild, but I think its true potential is only be
scratched on at the surface. I've been toying with 'the directed wiki'
approach, where you can have semi-structured content (like an organized
discussion list, a to do list, a job contacts, etc) that you use a
'specialized' client to edit. So, you can treat it like a normal wiki if
browsing with a normal browser, but if you have the special client the
server says here's the data, go nuts. The special client would know how to
format the data, and could use an editor of its choosing. That gets around
the poor editing in the normal browser environment.

Jim