Forum OpenACS Q&A: Re: Is there any tutorial for xowiki?

Posted by Gustaf Neumann on
As explained above, the widget spec of the richtext widget can be provided with a folder_id or a package_id of a filestore.

The widget-spec can be configured for every xowiki instance differently via the folder object. So, figure out, what folder_id or folder package_id you want to use and follow the instructions, how to configure xinha in a certain instance from

Posted by David Ghost on
Thank again Gustaf,
and I hope this time to be the final introductory questions .
Finally I succeed to change folder_id by using folder object...XoWiki document assum too highly educated person.
For me it was a huge obstacle to find out where & how
For clarity here I repeat my real step-in s
1. Go to admin page on any Xowiki instance
2. Locate xowiki::object and in there, identify folder object(named with numbers..)
3. Go to edit page and provide below code segment as a sample

set rich_text_spec {richtext(richtext),nospell,optional
{label Content}
{html {style {width: 100%}}}
{options {editor xinha folder_id 1618 height 350px javascript {

set widget_specs [list *,text $rich_text_spec]
4. Publish this revision
5. Verify the changed effect with normal xowiki page (i.e. index page)- you might let your server allow IMG tag to complete test

Gustaf, here I encountered trivial but annoying trouble
On later editing for the xowiki::object, I can't see the previous page content to be modified...any advise for this?

And here is (hopefully) last query on this thread
Xowiki document describe Programmable XoWiki Pages: ::xowiki::Object
Let me ask you one more time - how can I do it?
It reveals that still I fail to catch the basic concept of xowiki, doesn't it?

Posted by Gustaf Neumann on
What do you mean exactly by "Publish this revision" (4)? if this refers to clicking on the red "published" flag on admin/list, this is not necessary. The publish_status is an atribute of a content item, not a content revision. If you click on the flag to "make it green", you make it available to the public e.g. via syndication (rss), what you probably don't want. You said
On later editing for the xowiki::object, I can't see the previous page content to be modified...any advise for this?
Do you say, that when you are editing the folder object of the same xowiki instance again, you see always the default content? if yes, what versions are you using?

Concerning your question about ::xowiki::Object: This class is a means for a programmer to have full control over a page from a script and to keep the script in the content repository (with versioning, etc). This is not the basic concept of xowiki, but a feature handy for certain applications.

What is it, that you want to do? what happens, if you go to xowiki/admin, you press the add button on the line with :xowiki::Object, provide a name (e.g. myobj) and a title, paste the example from the manual and then OK. If you view the page, you should see the result of proc content displayed. You will find in xowiki/www/prototypes a few examples (like, some background about prototype pages is in

Posted by David Ghost on
I install xowiki (ver. 0.60.2) with official release of OACS 5.3.2 (upgraded from 5.3.1)
Specifically speaking, when I tried to edit folder object,
the content displays nothing though it keep working with previous scripts I entered.
The only way to check the existing content of folder object is to view it via clicking on it's name...

For the other xowiki object like CGI(instantiated from prototype) and myobj(created by me), the behavior is different. The whole content I entered wrapped with "{", "}" and "text/html"
...Ah, hard to explain, so here is my example,

{proc content {} {

return {Hello [[Wiki]]-World}

} } text/html

As a result, the "content" proc doesn't work at all as expected...(or as your document told)

The CGI & other pre-defined prototyped objects seem to work well only at first instantiation. that is once I modify the content of the instantiated object it turns out the text itself I provided.

Posted by Gustaf Neumann on
ok, i see what's happening. The bug you are reporting was fixed on Aug 9. The problem was that the rich-text widget spec specified in the folder object was applied to all form fields named "text", even in cases, where the form field must be a plain textarea (which has a different representation (just text) than the rich-text (text + input-mime-type)).

The problem is fixed now in cvs in the oacs-5-3 branch. You should be upgrade to the new version via "install from repository" after the nightly built of the .apm-files.

Posted by David Ghost on
I'm not sure how to upgrade
I'm quite novice to the method of upgrade you suggested.
Would you tell me more friendly way?
Posted by David Ghost on
Do you mean if I wait one or two days, then new xowiki will be available via "upgrade from repository"?
Posted by Gustaf Neumann on
there is as well the possibility to get the code via cvs (see how did you install xowiki on your machine?

yes, "install|upgrade from Repository" is what i suggested. The server on builds nightly packages, called .apm files.

Posted by David Ghost on
Thanks Gustaf,

Finally it seems to work as described.
I'm afraid that this very impressive package requires too much trial&errors and eventually my brain & coffee.
Whole my attention now caught by xowiki.
Also I'm afraid I am too late to find out xowiki deserves of developer's time.
I hope to be allowed to allocate most of my time for xowiki....Good luck Gustaf and Warm Regards thanks again

Posted by Gustaf Neumann on
many things are possible with xowiki based on configuration, some of the configurations are for the end-user, some of these are rather for programmers. Your requirements (use a certain folder/filestore) were quite special, some the programmer oriented configuration was necessary (editing folder object, which is the last resort). And unfortunately, there was a bug fixed only in the head version. So i hope this is not the normal user experience.

Hopefully, future versions of xowiki will be more easy to configure.


Posted by David Ghost on
Gustaf, issue is back again...
Some dotlrn related form which contains text(or richtext whatever..) doesn't show up at all when I set ACS Templating parameter to rte.
- for specific example, I encountered this trouble during trying to compose Welcome message for new-comer to certain dotlrn community.
To work out this trouble, I set that parameter to xinha.
But with "xinha", this time the trouble is that I can't translate some of "en messages" into "ko messages"
I bet you can understand what I mean if you try with the above real "Welcome message" case.

I'm not sure this is the right place to ask for answer.
cause it seems to be related with dotlrn-ware.

Posted by Gustaf Neumann on
Let me recap: you say

- this question has nothing to do with xowiki.
- editing the dotlrn form does not show at all with rte
- editing the form with xinha has trouble with Korean messages.

I assume, you are editing always with the client language settings of Korean. Correct?

Maybe the following can help you: xinha has its own javascript based message catalogs (currently for 33 languages, see packages/acs-templating/www/resources/xinha-nightly/lang/, there are additional catalogs for the plugins). I would recommend to add a Korean catalog named ko.js.

Posted by David Ghost on
Sorry for my late reply.
Most of my explaination fails to be clear...
-Not all dotlrn text form elements have trouble.
-With community Welcome message case, I'd like to emphasize on editing trouble on xinha for internationalization not only for Korean. Sorry I can't explain further detail about this you'd better neglect this.
By the way
Is it possible to install xowiki on oacs 5.2.4?
If so, let me know the detail procedure including related module which should be upgraded.
I posted it on separated thread but got no reply.