As explained in the document attached to the TWikiStoryOfWebTeach, our group at the University of Florence (Italy) is using TWiki as a collaborative tool for distance teaching. We would like to use it as generic front-end (i.e. a content manager).

Problems, features and call for comments:

---

Internazionalization.

As commented in LocalizationIsNeeded, our interface (see http://www.complex.unifi.it/WebComplex) is in Italian. I'm striping off all English strings from the sources and putting them into an hash (%Strings) in TWiki.cgf, e.g.

# view
$Strings{Edit}      = "Edita";
$Strings{Attach}      = "Allega file";
$Strings{Create}     = "Crea";
# The "Add form" button
$Strings{AddForm}     = "Aggiungi le categorie";
#Forms.pm
$Strings{Change} = "Cambia"; 
$Strings{DefaultTooltip} = "Clicca per vedere i dettagli in una finestra separata"; 
# rdiff
$Strings{Deleted} = "Eliminato";
$Strings{Added} = "Aggiunto";
$Strings{Changed} = "Cambiato";

Could it be included in the alpha version?

Templatization

I think that the best solution would be to eliminate any hard-coded string in the source and put them into the templates. This would imply enhancing the template syntax to include FOR and IF (in the spirit of the Template Toolkit TT2 (http://www.tt2.org).

Since most of people are satisfied with the present implementation of templates, I suggest allowing the use of TT2 as a plugin. Indeed, since there is an Apache::Template plugin, it is sufficient to apply the right directives in the httpd.conf file. However, there should be a way of passing the variables to the template.

So I suggest to modify the TWiki code in the following way: the core routines should collect information and put it into an hash (or an object). The rendering part should interpolate the variables into the template. In this way one can maintain compatibily and also allow experiments on a different kind of templates.

Persistence

In the same spirit, one should try to put all global variables into a hash (or object), maybe the same. In this way TWiki could be compatible with mod_perl, and one could think to make session data persistent, speeding up everything.

I already tried such a modification in a previous version, and it seems to work.

Authorization.

I would like to have the same authorization mechanism for several systems, so I developed an apache module (based on Apache::AuthCoockie) that allows user authentication against a database or the twiki .htpasswd file (or even the usual passwd file). It works trasparently to TWiki.

However, I need to control user access to the pub directories, with a privilege mechanism similar to what used for pages. This need arises because I want to use twiki as a generic front-end. Consider the quizz-generation problem: a teacher describes the quizz structure in a twiki page and attaches the question database. A cgi program builds the actual test page (in pdf) and attaches it to the page. The teacher retrieves the test. If students can download the test their life is too easy...

Using the described procedure I can forbid indiscriminated access to the pub directory, but not distinguish among registered users.

Ideas?

Syntax

The usual wikiwords do not render well in Italian, so most of our users tend to stick with the square-bracket mechanism. However, wikiwords appear in the index, etc. I would like to allow the use of underscores as an alternative way of indicating wikiwords.

In the wiki spirit, pages should be written like e-mail messages. I do not like very much the heading syntax, which is very different from e-mail. I suggest using underlining:

A Title           
=======

corresponding to <h1> A Title </h1>

                    A Centered Title      
                    ================

corresponding to <h1 align=center>....

A Subtitle
----------

A Subsubtitle
~~~~~~~~~~~~~

Since in this way one is obliged to read two lines before outputting, I suggest also the following rule:

If a line has an indentation greater that the preceding one, and does not begins with asterisk, number, hash sign or colon (see after), then it is considered a continuation of the preceding one. If the line contains only whitespaces, it is a break.

This allows to continue lists over paragraphs

 TAB 1. a numbered list
TAB TAB 
TAB TAB continuing 
TAB 1. Second item

and to write tables as

| first title, quite a long one
   | continuing with the second title
      | and the tird 
         |
| 1     | 2     | 3     |

I also want to have a way of referring to items in numbered lists, so I propose to have a mechanism similar to \label and \ref in latex:

..our goals are

   1. %LABEL{"FIRST"}%  bla bla...
   1. %LABEL{"SECOND"}% bla bla...

... as pointed in %FIRST% ....

which could be syntesized as

..our goals are

   #FIRST#.  bla bla...
   #SECOND#. bla bla...

... as pointed in %FIRST% ....

The same label mechanism could be used for sectioning, etc.

Finally, descriptions are presently manages using a single-word term followed by a colon. This is not suited to Italian, so I propose to use

   :a long description: bla bla

All these formatting extensions can be implemented as plugins.

Custom editors

Using a browser's text box for editing is quite frustrating (expecially if it cannot be resized): no syntax highlight, no spell check, etc.

I solved this in a triki way: I modified edit obtaining the print command, attached to this page. This command simply prints the content of a page with the mime-type text/wiki. One can thus configure his browser to launch the preferred editor on this mime-type. When one is done, he simply selects everything and pastes it into a (small) textbox. This is particularly simple in unix, where one can use the middle button of mouse to paste the highlighted text, but also works under windows using word. Carriage returns are selected by user's preferences, but could probably be selected according to browser's informations.

Synchronization

I want to use TWiki for distance teaching to jailed students. Due to security reasons, we shall use two distinct TWiki implementations, periodically synchronized using rsync.

How could it be done in a safe way? I was thinking to urging users to attach comments (which are pages on another or same web, using a particular plugin), since in this way there is less need to arbitrate collisions, but the problem is still present.

Ideas?

XmlRpc ?

Mathematics

As discussed in MathematicsWiki, I need latex. I tried hevea and tth, but the outcome is very poor, so I switched to latex2html.

However, it is very slow, so I was thinking to implement a cache mechanism which could also speed up the normal use of twiki:

• There is a cache directory tree (using the same mechanism of the pub tree). Pages are cached at save time, resolving all static pieces.
• When previewing, first the cache directory is duplicated

and the page is elaborated in this directory. This allows the reuse of images generated by latex2html

• When saving, this temporary directory is moved to the actual cache. It instead it is copied one can save time at following preview (avoiding the previous step), assuming that preview is done several times per edit.
• When viewing, the cached pages are still processed for dynamic evaluations, wiki links, etc.

I have not yet ported this mechanism to the new version, it was implemented using a different cache mechanism on view.

Wikization

One that one is accustomed to wiki, he would like to use this syntax also for other documents, like latex files and so on. So I suggest investigating a wiki converter to everything, that can be used for instance to generate the latex version of pages to be converted to pdf, etc.

-- FrancoBagnoli - 14 Mar 2002

Comments

Lots of good ideas in here - I would particularly like to see better support for ModPerl: at present you can only run one instance of TWiki under mod_perl, due to the global variables being shared across both instances.

Custom editors would make a big difference - perhaps an AppletBasedEditor is the way to go, as that can be more seamlessly integrated with TWiki. Another idea is to use a simple Java applet to launch a user-specified editor on a temp file, acting as a gateway to and from the Edit page.

-- RichardDonkin - 16 Mar 2002

As I pointed, I already ported an old version of twiki under mod_perl. It took about a week of work: I simply made it work under use strict, including all global variables in an hash inizialized at beginning.

I could redo it if there is a chance of having it included in a future release (otherwise it could lead to a new branch).

-- FrancoBagnoli - 16 Mar 2002

I'm interested in adding any ModPerl improvements to the core code, subject to other CoreTeam members agreeing of course. ModPerl is important to get good performance, especially on Windows where forking new processes is slow (I benchmarked a remote Linux box at twice the speed of a faster Windows box running TWiki locally - both not using mod_perl).

-- RichardDonkin - 16 Mar 2002

"We are going to formally start a public CVS based project to coordinate the WebTeach development." Curious to know when you'll have a CVS as mentioned in the .pdf This project sounds very interesting, I just wish my italian was better! The WebTest generator sounds very exciting.

Creating a form interface that is xml conformant is critical methinks. There are a variety of flashcard and testing apps already being used that could be easily integrated as interfaces for WebTest. Xcard/ Jlearnit/ Quizcards come to mind immediately and they are all XML based, though with different licensing schemes.

Test and answer creation should be as easy as possible. Perhaps with an applet? as the form creator for Twiki is a little too raw for 'average users' to tackle.

A quick review of Template Toolkit TT2 (http://www.tt2.org) I noticed that there is a DOM plugin in the toolkit http://www.template-toolkit.org/docs/blue/Modules/Template/Plugin/XML/DOM.html... so users could load an xml document into the wiki via TT (methinks).

Hopefully setting the plugin would be as easy as the TWikiDrawPlugin...

Again, if the XML is based on an XSD then all incoming data from the users could be validated and then parsed to generate the perl data necessary to deliver the content. Templates could be auto generated based on preset Element and Attribute selects in the XSL.

I'm very interested in hearing more on the templating mechanism between Twiki and WebTest. Thanks

-- DennisDaniels - 18 Mar 2002   (moved from TWikiStoryOfWebTeach)

More on WebTest in the WebTest page

-- FrancoBagnoli - 18 Mar 2002

Regarding mathematics: I've written a plugin called MathModePlugin that lets you include mathematics in TWiki page just like math-mode in LaTeX. Enclose your math strings in dollar signs, and latex2html is used to render images of the expression, which are then displayed when you view the page. Check it out, and tell me what you think.

-- GraemeLufkin - 04 Apr 2002