create new tag
, view all tags

Cocoa Based Wiki Editor

A Cocoa-based WikiEditor is an option to help at least the MacOS users use TWiki in a efficient way.

Although my discussion is based on MacOS and Cocoa, there is no reason not to use these ideias on other operating systems. I talk about Cocoa because that's what I'm working with right now.

A little background first

Ive been following the discussions about having a easier editor to work with TWiki.

For now, the approach I like best is EditDaemonWithGVimIntegration, but that's because I'm a VimEditor user and a programmer.

For "normal" user's, one of AppletBasedEditor or JavascriptBasedEditor.

Another approch is creating a API for TWiki allowing remote editing in a more general way. Some topics have been written about it:

I think that there is no need to have only one of the above, if you have a good infrastructure to make sure that these features don't need modifications to the TWikiKernel. One way of doing that is TWikiOO, but I haven't seen any progress in that ideia. I don't even know if gradually rewriting TWiki with a OO approach is an option. Would it be accepted by the core developers team?

Given all this, and knowing that no single approach will make everybody happy, I think that at least an OO approach to basic topic handling is requiered.

Recent news in Cocoa

At Mac World SF 2003, Apple announced a new browser named Safari. For me there are two cool things about this new product:

  • It's partially OpenSource: they are using the KHTML stuff from the KDE Project and apparently improving it and giving back to the comunity;
  • The HTML renderer, the core of the browser, is available as a Cocoa Framework, called WebCore.

The second part is the important part to TWiki. It will be possible soon (as soon as documentation on how to use that framework becomes available...) to use the same rendering engine of Safari in our own personal projects.

A Cocoa TWiki viewer and editor

With WebCore, we can easlly do a TWiki viewer. It's really just a browser, but more than that, we can develop a editing facility that can use WYSIWYG or similar technologies to make it easy for people to use TWiki.

These are the thing's I think will need to do this.

On the client side:

  • Documentation and examples of WebCore usage;
  • a HTTP client: I'm almost sure Cocoa includes something like that (NSUrlHandle, I think...), but we also have a Curl Framework, around libcurl. Also, I don't know yet if the WebCore framework will also have a HTTP client;
  • a text editor component: we can start with the builtin NSText stuff...

On the server (TWiki) side:

  • a API for topic handling: I think that PluginApiForTopicHandling will provide these goods. It will need a previewTopicText or something, but that should be trivial.
  • a XML-RPC or SOAP or even simple HTTP API on top of the topic handling API: these is new, and need's to be written;

I'm probably forgetting something... smile

How would it work

There are at least X operations that these client would perform. These is an approch on how it could work.


The TWiki login stuff is all HTTP basic authentication, so no special problems here. I think libcurl already deal's with basic auth.

Login and password can be stored in the MacOS keychain.

Viewing a topic

This is a browser, so nothing new to do here. Just browse away on your wiki.

Eventually, you could think on making thing's more advanced. It could be possible to do a special skin with enhanced features. The Client could have navigation toolbars that react to META tag's for example, like the Mozilla (worked in version 0.9.5, but aparently removed from version 1.0 due to performance issues).

Editing a topic

A big edit button can be placed in the UI. These would trigger the following:

  • using the remote editing API, get and lock the topic text;
  • startup a new window with the editor component. It has three buttons: preview, save and cancel:
    • preview would call the previewTopicText API. This would send the text to the TWiki server, have it translated into HTML, and sent back to the client for display (in a preview window maybe). The advantage of making the preview in the server is that full plugin support can be implemented;
    • save is simple: call the saveTopicText API, optionally removing the lock;
    • cancel is simple to: just cancel the lock.
  • search the wiki, can be implemented client side, at least the search form, making it more userfriendly;
  • TWikiForms could also have special treatment.


CocoaWikiEditorDiscussion is the place to tell me I'm crazy smile

-- PedroMelo - 12 Jan 2003

Edit | Attach | Watch | Print version | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r5 - 2008-09-12 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.