Using (AJAX) Async Javascript + XML technology in TWiki

Ajax is a framework that allows you to update displayed web page without doing a browser refresh. The requests for information update are sent via javascript which connects in the background and updates the DOM when the results come in.

Usability wise, this approach instantly enhances the web experience - by hiding the latencies and by providing uniform experience.

Within TWiki, this approach is very useful whenever we use forms; for e.g. Finding topics, comment plugin, table edits and so on. But the approach might require a complete rewrite of some components rather than incremental approach.

I have attached a sample code that uses Sajax - http://www.modernmethod.com/sajax/ - a toolkit that implements Ajax technology in various languages. This code allows you to see the list of all topics in main web that start with given partial string. To use this:

• Put attached twiki_topics code in bin directory
• Copy Sajax.pm from the said toolkit into lib directory (Use version 0.10)
• Use 'twiki_topics' in place of 'view' when you request twiki topic. (For e.g. http://myhost.com/twiki/bin/twiki_topics

• twiki_topics: Show list of topics that start with input string - using Sajax

Like Google Suggest, this could be enhanced to make it use tab completion to go to topic you want.

-- VinodKulkarni - 25 Mar 2005

wow, thankyou Vinod, I was going to start playing with ajax this Easter long weekend, and now you've siplified it for me!

here's the patch to make it work for DEVELOP

sven:/usr/lib/cgi-bin/DEVELOP/bin# diff -u ../../twiki/twiki_topics twiki_topics 
--- ../../twiki/twiki_topics    2005-03-25 14:25:41.000000000 +1100
+++ twiki_topics        2005-03-25 15:18:30.000000000 +1100
@@ -26,9 +26,7 @@
 
 my $q = new CGI;
 
-my( $topic, $webName, $scriptUrlPath, $userName ) = 
-  TWiki::initialize( $q->path_info(), $q->remote_user(),"", $q->url, $q);
-
+my $session = new TWiki( $q->path_info(), $q->remote_user(),"", $q->url, $q);
 
 # ========== Perl based Sajax =========================
 # Perl version cloned from the original PHP by http://www.modernmethod.com/sajax/
@@ -54,7 +52,7 @@
 #equivalent modperl methods
 
 # my @topics=("ThisOne", "Vinod", "Anderson", "StandardTopics", "Bala", "Cat");
-my @topics = &TWiki::Store::getTopicNames("TWiki");
+my @topics = $session->{store}->getTopicNames("TWiki");
 my $getTopics = sub {
     my($partial)=@_;
     my $matchedStr = "";

-- SvenDowideit - 25 Mar 2005

One use case: We could use it to add example markup code within the edit window - without leaving edit window or using a pop-up.

-- VinodKulkarni - 25 Mar 2005

Making ajax technlogy javascript free using wikis:

I have been able to make this code usable in a standard wiki topic. I tried this with 'ttview', which is a template-toolkit based view that I am trying out. The approach looks promising. Here are the themes that I am trying:

We first create a set of routines for ajax data pull. For example:

• List of topics in web.
• List of items in a list.
• Specific row in a table
• Specific block of text

These routines can be in independent perl module (in which case, they are available to all topics.) We can let each web/topic have specific such routines (though we would have to allow sysadm to enable writes in specific directories.)

And we patch 'view' and other such usual perl binaries with following functionality:

• Integrate Sajax with them. (It is called conditionally only if topic is going to use ajax calls.) This can only be checked by grepping for some specific variables/macros within a topic (or using web/topic variables.)
• Sajax gives a bunch of javascript code that we should be able to insert inbetween head tags. This can either go into templates, or even in topic (using script tags). I could succeed with latter. To avoid use of templates, I added a new param to $query, and I just used %URL_PARAM{sajax_javascript}% to emit the said javascript.
• The same view/edit script should also behave as equivalent of a web-service - when sajax passes some special parameters (as part of async javascript call as result of UI interaction). The HTML for this is different, and decided by Sajax. So the result of view/edit/.. script is conditional. (If Sajax produces output, then produce customized HTML, otherwise produce standard, twiki-rendered HTML.)

So the end result of all this is the following use case (as example). We assume a set of useful methods written in perl, and placed in a .pm file within twiki setup.

• Define a list of items in a topic. (Let us assume users topic.)
• Use a sample Form in a twiki topic which allows drop-down list of users. And you want dynamic word completion using ajax technology. Go ahead and just use some simple markup (of known routines) within the form.

And phew! You have this with almost no knowledge of javascript.

-- VinodKulkarni - 31 Mar 2005

http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg03078.html describes an approach for using the AJAX concept with CPAN:CGI::Application

-- WillNorris - 10 May 2005

a wiki http://lesserwiki.org/ already used AJAX and maybe it can give us some idea what will it look like...Though it used japanese and is really slowww..anyway we can still test it.

• This is a TiddlyWiki implementation. -- ArthurClemens - 06 Aug 2005

Another issue is that Is it a good idea to write a small chat room something by AJAX? Since the traditional message program, chat room and forum is not topic-oriented and the forum shipped w/ twiki is 2 formal and only good for public disscussion. What about the private chat w/ the topic, can we have a small private chatroom to let people brainstorm and publish later if it get mature?

-- KingstonFung - 06 Aug 2005

I guess, my initial reaction is - that sooo not wiki, but it would be interesting to see what happens if you implement it

-- SvenDowideit - 07 Aug 2005

O.K., with three exceptions (one minor, one not so minor, and the speed, which may be a problem of the site, or could be a slow implementation) I really like the leserwiki site. Not something I'd want to replace TWiki with, but it would be very nice for our (the company I work for) intranet site. For that reason, the balance of my comment applies more to this specific implementation.

Bias disclosure: I really like what AJAX-type technologies can do for a site. However, that said, I firmly believe in non-javascript fallbacks.

First, the major problem: it falls for the big problem many heavy javascript site falls for. href="javascript:" is seriously broken for several reasons. The most obvious is that the site won't work without javascript being enabled. More subtly, it means that I can't open a link in a new window or tab.

I've done a bit of work with AJAX-like technologies, and with a few categories of exceptions, it's not hard to have non-javascript-dependant fallbacks. I see nothing on that site that couldn't EASILY have non-js fallbacks.

The minor issue is the lack of a WYSIWYG editor. I know, many people don't consider a WYSIWYG editor a plus, but here (again, the company I work for), it's manditory.

-- EricSchwertfeger - 08 Aug 2005

Just for the records, the new rest script in DakarRelease allows to implement the AJAX backend as a TWiki plugin, without additional CPAN modules required.

-- RafaelAlvarez - 08 Aug 2005

erm, Eric - have you seen the Wysiwyg editor thats being developed in DevelopBranch? we not only consider it important, but I'm pretty much betting that there will be a good set of structural changes to TWiki that will be inspired by it.

-- SvenDowideit - 08 Aug 2005

I think he's refering to the lack of a WYSIWYG editor in leserwiki.

I really like the "in place edit" stuff it has (something that should be integrated in the SectionalEditPlugin family, IMHO).

-- RafaelAlvarez - 08 Aug 2005

Has anybody seen this? http://www.wikyblog.com/ Or even this has some good concepts: http://wikiwebhelp.org/#2-en.

I've been searching all over for a really good open source wiki solution, and I'm surprised that the more popular systems (including TWiki) barely seem to use ajax at all. If all of the excellent plugins and features of TWiki were coupled with a more modern interface that doesn't rely on full page loads to do everything, it would be a huge improvement for my purposes.

Maybe it's time for me to start doing some contributing. And I told myself I'd never go back to perl ...

-- AaronWebb - 2010-08-11