Forum OpenACS Development: xowiki 0.20

The new version xowiki 0.20 is in CVS head. Since 0.18, i have added various features like e.g. search, import/export, configuring start page, programmable wiki objects, plugin for categories etc. to XoWiki. The documentation reflects most of the new stuff, the sections Folder Object, ::xowiki::Objects, import/export are new. For understanding ::xowiki::Objects, see the hello world example.
http://media.wu-wien.ac.at/download/xowiki-doc/index.html

For fun, i have modeled the oacs home page as wiki page. The structure is decribed in the documentation as well.
http://media.wu-wien.ac.at/download/xowiki-doc/oacs-home-page.png

For people not using CVS, get the apm-files for xowiki and xotcl-core from http://media.wu-wien.ac.at/download/

Nima,

I agree. We just need someone to make the Selva theme work on a stock openacs install without .LRN.

Coolness !!!!

I don't know if this will help reduce the code in the "content-part" but I put together a little Ajax Helper package that uses the prototype.js and scriptaculous javascript libraries.

It's currently in use in a custom Tag Cloud package in Solutiongrove's Aspen Private Label Communities product and an ongoing project that uses xowiki and portlets.

The package also allows you to use tcl to generate the javscript for cinematic effects like fades and transitions so you can actually put transition effects when the chat screen is updated via ajax.

I was hoping to commit it to OpenACS Head once I've completed the documentation and demos.

Hi Gustaf,

These are the same big questions that I dealt with when I was looking into xmlhttpd about 1 year ago when it started gaining momentum. But then things got busy and I was unable to pursue it.

It's a good thing too because between then and now a plethora of javascript libraries and ajax toolkits have been released that address those same questions.

I've just committed to OpenACS CVS Head the Ajax Helper package. Instead of re-inventing the wheel I decided to re-use what is available by utilizing Scriptaculous and the prototype javascript library.

http://cvs.openacs.org/cvs/openacs-4/packages/ajaxhelper/

A demo site will follow very soon.

Cheers,

Hamilton

Hi Rainer,

Thanks for the feedback.

Hamilton

wow; this is looks indeed very nice! maybe this is developing to an alternative to the portlets + portal pages...

another thing to mention: in the current version, a user cannot chat to himself: in order to minimize the traffic, the chat remembers for every user_id the timestamp he has already seen, and sends only newer messages (happens via nsv_*). so one needs 2 users to try this out.

Indeed, this looks fantastic. A couple of Qs.

1) Does this work in 5.2.x ? Pardon if I missed this.

2) If so, how can this be tracked with cvs in a 5.2 installation?

3) Does this depend on .lrn features? Q comes from looking at the png of your demo OACS home page, and from comments on your doc page.

Thanks!

Hamilton, i will give this library a look, when i have again some ajax needs.

For now, i've commited a new version of xowiki, supporting nicer urls (e.g. pages/en/gustaf instead of pages/en%3agustaf); in addtion, we have now a page_title to be used instead of lang:shortname and a creator (to be used for RSS) for all types of wiki pages.

well, the reason, why en:gustaf looks bad with oaces lies at least in part in the ns_urlencode, which i did not want to cirumvent. wikipedia uses unencoded colons in links (see http://de.wikipedia.org/wiki/Bild:Netz_ASEAG_um_1933.png). Anyhow, moving from en:gustaf to en/gustaf is a simple step, and makes the user think, there is a directory of english pages, which sounds like a good metaphore to me. this is certainly as well a very crawlerfriedly version. Using /en as a suffix sounds not so good to me, but this is rather a subjective argument. by any of these nameing rules we are reducing the range of valid names; e.g. "a/b/c" is so far a valid name of a page, Telling a user, "use $lang/name" sounds to me as a more intitive rule than "name must not end with /$lang" or similar. The overall wiki conventions are based on prefixes, so why to switch to suffixes. Certainly, using "?lang=en" is an option as well, but the basic idea of nice urls is to make these free of query parameters...

making the language optional is not something i would emphasize right now, since this can lead to serious misunderstandings, depending on how the default language is determined. If this is based on the user preferences, a link like pages/gustaf would lead to a page of the users prefered language. however, what if the pages in these languages are sparsely populated, etc. If two people look at a page wuth the same link and they see different pages, this can lead to some confusion. The automatic language completion sounds more suited for a well maintened set of pages (e.g. learning materials) than for a rather chaotically developed set of information chunks. So by default we should be precise on the links. btw, the language can be made optional in all variants.

Remember, we are talking about the links showing up in the listing of all pages, or from the category listings, or between wiki pages. Within a wiki page, a user will/should use [[gustaf]], or [[en:gustaf|Gustaf Neumann]] or whatever to refer to appropriate page. The links from wiki pages are generated at the time of rendering based on the language preferences. We are talking about beauty of these generated urls....

i have added some small enhancement to xowiki, that some of you might find useful. In a large repository of wiki entries, it is not so easy to find out, what has changed. therefore i have added two includelets. The first one ("categories-recent") shows the n most recently edited pages by categories, somehwat similar to the Recent Posts of oacs.org. The second one ("recent") is a simple flat listing of the n most recent edited pages.

>right-col<<
{{adp portlets/categories-recent {name {Recent Entries by Categories} max_entries 5 tree_name Purpose}}}
{{adp portlets/recent {name {Recent Entries} max_entries 10 }}}
><<

This snippet is shown rendered in the left side of the screenshot
http://media.wu-wien.ac.at/download/xowiki-doc/recent-entries.png

The changes are in cvs HEAD as usual.

Dave,

The real problem with xowiki on openacs.org seems that it is not possible to create items derived from ::xowiki::Page. if you try to add a new "xowiki plain page" there, you see the same message as showing up with the folder object:

Database operation "dml" failed (exception ERROR, "ERROR: insert or update on table "xowiki_plain_page" violates foreign key constraint "xowiki_plain_page_ppage_id_fkey" DETAIL: Key (ppage_id)=(395917) is not present in table "xowiki_page". ")

The same happens, when trying to create page templates. Here is the type hierarchy of the pages.

      object_type       |      supertype
------------------------+---------------------
 ::xowiki::Page         | content_revision
 ::xowiki::PlainPage    | ::xowiki::Page
 ::xowiki::PageInstance | ::xowiki::Page
 ::xowiki::PageTemplate | ::xowiki::Page
 ::xowiki::Object       | ::xowiki::PlainPage

An insert with content_item__new into with a object_type of e.g. ::xowiki::PlainPage is supposed to insert into xowiki_plain_page and xowiki_page. This works normally nicely, but seems to fail on openacs.org (interpreting the above error message). The same thing happens, when xowiki tries to create the directory object (of type xowiki::Object), which makes under normal conditions an entry in xowiki_object, xowiki_plain_page and xowiki_page. This was the place, where the error popped up.

Either there is something seriously wrong with the handling of derived types in the CR on openacs.org, or something went wrong already with earlier installations of xowiki.

Since you have only ::xowiki::Page objects so far, before digging into the details, i would recommend to go to the admin interface xowiki/admin and delete there the types for Object, PlainPage, PageInstance and PageTemplate. If you can delete these, reload xowiki from apm, and the types should be recreated magically.

If something is seriously wrong with derived types in the CR, this won't help either, but maybe something went wrong with the definiton of e.g. PlainPage in earlier installations....

oncerning xinha: by looking into the HTML source of an edit page from openacs.org, i see that the xinha javascript is not included in the edit pages. didn't you set the "htmlarea_p" to 1 in the oacs.org installation of xowiki (since the global UseHtmlAreaForRichtextP is not set?)

Hope, this helps...

Well, got the bugger: The problem is a Postgres 7.4 vs. 8.0 issue, sitting in acs-content-repository/postgres/content-type.sql. The content-repository code in the current oacs-5.2.2 produces rules that insert for derived datatypes the tuples in the wrong order. The insert for xowiki_plain_page triggers the
fault mentioned above, since the key inserted into derived type (xowiki_plain_page) is not yet in the supertype (xowiki_page)

 xowiki_plain_page_r AS
    ON INSERT TO xowiki_plain_pagei DO INSTEAD
  ...
 INSERT INTO xowiki_plain_page (ppage_id)
  VALUES (cr_dummy.val);
 INSERT INTO xowiki_page (page_id)
  VALUES (cr_dummy.val);

If the order is changed, it works fine

 xowiki_plain_page_r AS
    ON INSERT TO xowiki_plain_pagei DO INSTEAD
  ...
 INSERT INTO xowiki_page (page_id)
  VALUES (cr_dummy.val);
 INSERT INTO xowiki_plain_page (ppage_id)
  VALUES (cr_dummy.val);

I played as well with deferring the checks, but this did not seem to work.

dave, you find the fixed rule generator in george:~gustafn/create-rule.sql

Most likely this will fix the bug #2810 as well
https://openacs.org/bugtracker/openacs/bug?f%5fcomponent=56190&format=table&f%5fstate=7&bug%5fnumber=2810&project%5fid=56106

The same should happen with all other apps with derived types using the postgres rules for updating the views. But i guess, there are not to many apps stressing the CR in this respect as much as xowiki....

I did not upgrade the xowiki on the test-server, since we forgot the permissions for upgrading xotcl-core. But i am quite confident, that things will work nicely now. On oacs.org, updating the rule-generator +

select content_type__refresh_view('::xowiki::PlainPage') from dual
select content_type__refresh_view('::xowiki::PageTemplate') from dual
select content_type__refresh_view('::xowiki::PageInstance') from dual
select content_type__refresh_view('::xowiki::Object') from dual

+ reboot should do the trick for xowiki.

Hello Gustaf,

I would like to have a look of your ajax based chat package. I've tried to install xowiki, but i get the following error when attempting to reach a page like http://servername/xowiki/index

----------------------------------------
invalid command name "::xowiki::Page"
while executing
"$supertype require_folder -name xowiki"
invoked from within
"if {![info exists folder_id] && ![info exists object_type]} {
set folder_id [$supertype require_folder -name xowiki]
set index_page [$folder_id ge..."
("uplevel" body line 18)
invoked from within
"uplevel {

etc...
----------------------------------------

What am I doing incorrectly?

I am quite interested in any chat package because of one of them is needed in IMS-LD, so we will integrate our develops with a chat package.

Thanks in advance,

Luis

... Have you xotcl and xotcl-core installed? on your system?

Gustaf, although you may have explained it before in response to other issues, could you please tell us what both packages do? Newbies, interested in XOwiki, will go for the full Monty, and never think about any conflicts between the packages as long as they are not made clear, hence will find themselves in trouble if installing both.

Is there no way to add a simple description to the functionality, in order to prevent people from crashing their system.

Maybe off topic, I notice XOwiki uses Xinga as editor, but OACS is shipped with the standard editor, offering less functinonality. Although not your department, we might need to find a way to sort this issue.

Cheers
Ben

Hello again,

I have installed all the software and the chat works well. The problems was xotcl compiling and installation, which i did incorrectly.

Thank you for your comments and help.

About the chat... this is a great job, i will research a little bit more to find how difficult and appropiate is the integration of this chat with IMS-LD conference service.

Cheers,
Luis

The "streaming" mode described above does not work with IE. MSIE flags correctly readystate ==3 when partial data arrives, but it does not allow to access the response text (like e.g. in firefox).

so i have defined yet another delivery interface for streaming data via ajax that seems to be quite robust: instead of sending JSON encoded java script objects, it uses now a hidden iframe that recieves a text/html file in streaming mode, which includes SCRIPT-tags containing the javascript calls. i called this mode "scripted-streaming". scripted-streaming works with Firefox, Safrari and IE.

The biggest disadvantage of scripted-streaming over streaming is that while the iframe loads (always) the activity indicator spins, which makes me nervous. so, when libthread is available, firefox uses "streaming" mode, the other browsers use "scripted-streaming" mode. When no libthread is available, "polling" mode is used for all browsers. One can certainly force the mode by specifying it as shown above.

xowiki chat is at least a study how to use AJAX with oacs in three different ways.

Gustaf,

This is really cool.

If my understanding of this article is correct
http://www.irishdev.com/NewsArticle.aspx?id=2173

We have here a COMET Web application !!!!

Hamilton

The new version of XoWiki in CVS has new functionality to track the last visited pages of a user and to track the most popular pages. This functionality can be turned off or on via a new package parameter called user_tracking on a per instance basis. The two includelets are described in the documentation http://media.wu-wien.ac.at/download/xowiki-doc/index.html .

Hope, someone finds this useful...

xowiki is not a cvs module. Use instead:

cvs -d:pserver:mailto:anonymous@cvs.openacs.org:/cvsroot checkout openacs-4/packages/xowiki

we had a severe fire damage. the machine is being replaced, most probably it will be down until early next week.

vandalism fighting is more of an issue when anonymous users edit or add pages. the site administrator can define who gets edit permissions on an xowiki instance basis. oacs has means to ban users. xowiki has variuos means to locate recent modifications and keeps a history of the changes that one can switch back to earlier versions.

I am not saying that we don't need better mechanism for such purposes, but we are in a different situation than the oridinary wiki. Currently i am more thinking about making the package more powerful.

btw., the good thing of an open source project is that everyone can contribute...

OpenACS can ban users, but not IP-addresses. The only way to stop vandals is to require user approval before they can join which is a bit against the Wiki idea.

Good point. By looking the the increasing number of spam content on openacs.org, it looks like a good idea to ban sites (i.e. not allowing a login from banned IP-addresses or subnets) as well. The same mechanism could be used for all user-contributed content, i.e. wiki-pages, forum posts, comments on pages, oacs company listings, etc...