Could you upload the patch somewhere? And did you commit XoWiki to the CVS in the 5.2 branch (or head for that matter). This is definitely something with which I can finally put ETP to rest for our site, at least from the looks at it.

As for Xinha, is it possible to reduce the number of features using a parameter in acs-templating and thereby make it quicker to download?

Furthermore, has anyone thought about a method to support multiple editors within OpenACS?

xinha is not the "perfect" solution, since it is a little slow on displaying. It is not only the number of options that cause this. however, xinha is functionally quite good and has many of the problems removed that existed as well in the lastest revisions of htmlarea (e.g. focus problems in tables). xinha has a good plug-in model and produces resonable code. we have developed such an image selection-plugin for learn@wu to choose images from certain folders. when i find the time, i will clean it up and make it available...

For now i will make a simple hack to make xinha coexisting/easy switchable with rte and check this into 5.2 if nobody objects.

Hmm, if you check your log-file, you see some earlier error during schema generation. Sorry for that, a result of an untested cleanup, this code is not run when the schema is already there. i did a fresh install on a 5.1.* oacs and found that i used as well a call of the cr-interface introduced in 5.2; i have removed that as well and detected a missing localize entry in xowiki as well, so i upgraded all
version numbers:

• xowiki-0.7.apm
• xotcl-core-0.19.apm

hope, i have got it right by now....

ok, i have made the check for the dotlrn communities conditional in my local version.

as announced, i have as well committed the change for xinha support to cvs 5.2. per default, rte is used as before. when one sets the line

set richtextEditor xinha

in template::widget::richtext, one can switch easily to xinha. It should be quite simple now to add a parameter....
Affected files are

• www/blank-master.adp
• www/blank-master.tcl
• packages/acs-templating/tcl/richtext-procs.tcl

However, i was not able to add the xinha sources to
packages/acs-templating/www/resources/xinha-nightly/

i always get some messages like:

cvs commit: failed to create lock directory for `/cvsroot/openacs-4/packages/acs-templating/www/resources/xinha-nightly/plugins/FindReplace' (/cvsroot/openacs-4/packages/acs-templating/www/resources/xinha-nightly/plugins/FindReplace/#cvs.lock): No such file or directory
cvs commit: lock failed - giving up
cvs [commit aborted]: lock failed - giving up

i am not sure, what i have done wrong, but i am giving up by now (5 o'clock in the morning).
can someone please get the xinha sources from its web site and place it there?

thanks -gustaf

I would recommend to commit this work in oacs-5-2 since from what I see XoTCL can be installed optionally.

Upgraded from an older version of xowiki and tried to create a new page. But got this:

Database operation "select" failed (exception NSDB, "Query was not a statement returning rows.")

FEHLER: Spalte »link_type« existiert nicht

SQL: SELECT page,ci.name,link_type from xowiki_references, cr_items ci where reference=1456296 and ci.item_id = page
while executing
"ns_pg_bind select nsdb0 {SELECT page,ci.name,link_type from xowiki_references, cr_items ci where reference=1456296 and ci.item_id = page}"
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql]"
("postgresql" arm line 2)
invoked from within
"switch $driverkey {
oracle {
return [uplevel $ulevel [list ns_ora $type $db $sql] $args]
}
..."
invoked from within
"db_exec select $db $full_statement_name $sql"
invoked from within
"set selection [db_exec select $db $full_statement_name $sql]"
("uplevel" body line 2)
invoked from within
"uplevel 1 $code_block "
invoked from within
"db_with_handle -dbn $dbn db {
set selection [db_exec select $db $full_statement_name $sql]

set result [list]

while { [db_get..."
(procedure "db_list_of_lists" line 9)
invoked from within
"db_list_of_lists references "SELECT page,ci.name,link_type from xowiki_references, cr_items ci where reference=[my page_id] and ci.item_id = page""
(procedure "references" line 4)
::xotcl::__#0 ::xowiki::Page->references
invoked from within
"$page references"
invoked from within
"set references [$page references]"
("uplevel" body line 24)
invoked from within
"uplevel {
ad_page_contract {
view a wiki item

@author Gustaf Neumann (gustaf.neumann@wu-wien.ac.at)
@creation-date Oct 23, 2005
@cvs-i..."
(procedure "code::tcl::/www/unima0/packages/xowiki/www/view" line 2)
invoked from within
"code::tcl::$__adp_stub"
invoked from within
"if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is up-to-date
adp_init tcl $__adp_stub
..."
("uplevel" body line 3)
invoked from within
"uplevel {

if { [file exists $__adp_stub.tcl] } {

# ensure that data source preparation procedure exists and is up-to-date
adp_init t..."
(procedure "adp_prepare" line 2)
invoked from within
"adp_prepare "
(procedure "template::adp_parse" line 30)
invoked from within
"template::adp_parse [file root [ad_conn file]] {}"
(procedure "adp_parse_ad_conn_file" line 5)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$path""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/$path"
set tcl_url2file([ad_conn url]) [ad_conn file]
set tcl_url2path_info..."

I am pleased to annonce a better and improved version of XoWiki. The following are the most important changes:

• Support for different types of wiki pages. Included is support for the rich text and plain text interface. In general, pages can differ much more. See bottom of the documentation page mentioned below.

• Initial support for nested wiki pages (not yet updating the links of the including page, not yet using typed links to indicate inclusion structure, but checking recurion depth).
  Example: {{adp portlets/wiki {name en:GN}}}

• Some code reorganizations: Better structure, less passing around of form arguments, better access to relevant data in including adp-pages. Added recursion count for nested wiki pages.
• Moved images to www/resources

• Removed dependency on dotlrn (thanks to Dave pointing this out)

Brian, it should be quite simple now (famous last words) to hook in your plain-text parser. Just check out

CrWikiPlainPage instproc substitute_markup

in xowiki-procs.

For more details and sources, see http://media.wu-wien.ac.at/download/xowiki-doc/index.html

Gustaf,

You can put the files under /packages/acs-templating/lib/

The /lib/ directory under a package is the standard location to put includable adps.

This sounds like a great addition, I can't wait to try it out.

Hi Gustaf,

xoWiki is amazing! xoTcl will be a great addition when fully integrated in OpenACS 5.2. Thanks for your support and sharing.

File-selector as you implemented using xinha plugin is a great idea.

A problem i had trying file-selector:

OacsFs xinha plugin files in acs-templating/www/resources/xinha-nightly/plugins/OacsFs
were not commited to oacs-5-2 branch. They are only in HEAD for now.

thank you, Gustaf. It is into oacs-5-2 now

One more stuff i needed to do to get oacsFS plugin working is about a type error in xowiki/www/xinha/file-selector.tcl file

In lines 121 and 130 i changed package_id switch value in proc fs::add_file from

fs::add_file \
...
-package_id $package_id

to

fs::add_file \
...
-package_id $fs_package_id


\Orzenil

Dave wrote

You can put the files under /packages/acs-templating/lib/

I believe, this does not help much, since the tcl/adp pairs insert-image, insert-ilink and file-selector are called from java script. We cannot call http://.../acs-templating/lib/xinha/insert-image directly through the request processor. The actual call must come from a mounted package like xowiki (where we could certainly use the adp-include), but this seems not perfect as well, since every app using xinha+file selector must do this. Or is there some other trick?

Orzenil,

i assume, you got this message when inserting an image, not a link. Your fix appears correct, but insterestingly, this error does not pop up on the java script console of Firefox 1.0.7 of my mac os x box. Your fix will be included in the next release.

although i have not tested it with the most recent nightly version, at least earlier version of xinha worked with IE.

Orzenil, i found and fixed locally the showstopper for xinha + oacsfs for IE. i have to rush now, but will check in the changes this evening.

Gustaf,

Thanks very much for the work that you have done on this module. I think it will be very useful.

I have installed it in a default installation of the 5.2 branch, and seem to be running into a problem when viewing items. I can edit and create new items just fine, the error comes when viewing.

Here's an url to my dev site, you don't need a login to see the error, just click on the view icon: http://coastalportraits.org/xowiki/

I've pasted the first few lines of the stack trace below:

::xotcl::nonposArgs: unable to dispatch method 'Boolean'
while executing
"::xotcl::nonposArgs Boolean adp on"
invoked from within
"::xotcl::interpretNonpositionalArgs $args"
(procedure "render" line 2)
::xotcl::__#0 ::CrWikiPage->render
invoked from within
"$page render -adp on"
invoked from within
"set content [$page render -adp on]"
("uplevel" body line 29)
invoked from within
"uplevel {
ad_page_contract {
view a wiki item


Any ideas what I should look at to debug this issue?

Thanks,
Ivan

Gustaf, thank you for the fix, it is now working for me.  The only other bug I've found is a minor dependency issue, I've added the following to my xowiki.info file to resolve this:

<requires url="categories" version="1.1d4"/>
<requires url="file-storage" version="5.2.0d8"/>

Thanks again!
Ivan

Gustaf,

I just tried to compile thread 2.6.1 with the command:

sudo ../configure --enable-threads \
--prefix=/usr/local/aolserver \
--exec-prefix=/usr/local/aolserver \
--with-aolserver=/usr/local/aolserver

as specified in your documentation, and got the following error:

checking for correct TEA configuration... ok (TEA 3.1)
checking for Tcl configuration... configure: WARNING: "Cannot find Tcl configuration definitions"

Turns out that you need to specify the location of TCL. Would you be able to update your documentation with the --with-tcl flag, as follows:

sudo ../configure --enable-threads \
--prefix=/usr/local/aolserver \
--exec-prefix=/usr/local/aolserver \
--with-aolserver=/usr/local/aolserver \
--with-tcl=/usr/lib/tcl8.4

Nick,

concerning libthread compilation: the need for --with-tcl depends on the local configuration. you are right, --with-tcl should be mentioned. btw. xowiki does not depend on libthread.

You are also right about the general comments dependency. Either i add the dependency or make the code conditionally. The blueprint concepts make me lazy in defining this dependencies, and does not scale well when the number of packages grows....

Is there a general rule when to add dependencies? Is it correct to assume that every package required and not staring with "acs-" needs a dependency?

Hi Gustaf and all,

I'm still running OACS 5.1.5 on my production server. Any chance I'll be able to cajole XOWiki into working on that version, or am I asking for trouble?

Thanks!

Joe, i have committed a verison working with 5.1.5 to CVS head, which has PageInstance and PageTemplate deactivated. When someone fixes the magically created views NAMEi and NAMEx to include the extra attributes like in 5.2, xowiki would work most probably completely with 5.1.

Joe, please do and the community will be forever grateful, as this means we can convert *our* docbook as well into Wiki and therefore effectively maintain the documentation without the docbook hurdle.

Since you have no page instance in your list, my guess is that the error does not occur during edit, but in an page create, when you press "add ...".

The error message indicates that the automatically created view does still not have the extra attributes (page template).

from psql, you should see:

# \d xowiki_page_instancei

            View "public.xowiki_page_instancei"

       Column        |           Type           | Modifiers

---------------------+--------------------------+-----------

 object_id           | integer                  |

 object_type         | character varying(100)   |

 object_title        | character varying(1000)  |

 object_package_id   | integer                  |

 context_id          | integer                  |

 security_inherit_p  | boolean                  |

 creation_user       | integer                  |

 creation_date       | timestamp with time zone |

 creation_ip         | character varying(50)    |

 last_modified       | timestamp with time zone |

 modifying_user      | integer                  |

 modifying_ip        | character varying(50)    |

 tree_sortkey        | bit varying              |

 max_child_sortkey   | bit varying              |

 revision_id         | integer                  |

 title               | character varying(1000)  |

 item_id             | integer                  |

 data                | text                     |

 text                | text                     |

 description         | text                     |

 publish_date        | timestamp with time zone |

 mime_type           | character varying(200)   |

 nls_language        | character varying(50)    |

 page_instance_id    | integer                  |

 page_template       | text                     |

 instance_attributes | text                     |

 page_id             | integer                  |

so, i guess there is something left in the database from your last attemtpts from earlier versions. I would try to get rid of the definitions of the page instance.

try xowiki/admin and drop the type + table from there. if you don't see this type, you might try "::xowiki::PageInstance drop_object_type" from the ds/shell.

if this does not work either, drop the page_instance* tables manually and delete the object type: delete from acs_object_types where object_type like '%PageInstance%';

when you restart your server, xowiki will recreate the tables/views on the fly.

btw, the page template on your site does not contain @-variables, so the page instance will look exactly like the template. look into the html documentation for examples.

Ps: i cant recreate the problem on your site, since one needs an account for adding items.

help this helps

Get the new version from CVS head.

Ben,

you should be able to install it from
http://media.wu-wien.ac.at/download/xotcl-core-0.30.apm
http://media.wu-wien.ac.at/download/xowiki-0.17.apm
from from server via /acs-admin/apm/package-load, provided that you have xotcl akready installed.

i have no idea how openacs.org/repository works, but this would be certainly a more convenient approach from upgrading packages for non-programmers. an alternative approach would be t allow access to the cvs repository via a oacs-web interface.

Has someone a working example for a single select and multiple choice question using xowiki::Form?

If I use html form direclty the options are missing:

<form>
<select name="standards">
<option value="1" selected="selected">1</option>
<option value="2">2</option>
<option value="3">3</option>
</select>
</form>

q1: every form-field-spec in the form constraints is a Tcl list element. therefore use

Form:
@mc@

Constraints:
{mc:select,required,options={yes 1} {no 0}}

q2: There is a but in some tdom versions that convert the given text to

<form>
<select name="standards">
<option value="1" selected="selected"></option>1
<option value="2"></option>2
<option value="3"></option>3
</select>
</form>

which is not displayed. an upgrade of tdom from cvs should help.

q3: unknown variable 'myvar'
The message says, that there are form entries in your database that have this variable not defined. This is most likely due to the fact that you have changed to form after some instances got some values. Most likely, you can deleted some earlier form instances to get rid of the warning message.

oops, i missed q0: examples:
Here are single and multiple choice questions: http://alice.wu-wien.ac.at:8000/xowiki-demo/klausur
some more examples: http://alice.wu-wien.ac.at:8000/s5-xowiki-060/slides

i have added the export of the demo examples above to http://media.wu-wien.ac.at/download/xowiki-forms-demo.export

hmm, it works for me (without form constraints). you say, you get the message after filling out the form? what version do you use?

Is there support for boolean expressions in PageTemplate and Form (Template) like in acs templates? This would allow customization of the display attributes according to their value.

Gurstaf, how would you recommend realising a small workflow? I would like to trigger an event after submit according to user entry like registration, package instance creating, confirmation email.

i have this on my todo list, a convenient solution will still take some time. As always, a quick solution is easy, a full blown one is more complex. Quick solution: to fire an action in certain situations, subclass Form and FormPage and overload methods called in the interesting situations (e.g. the method save_data). This allows to call application specific calls before or after the methods in question.

if you want to go that way, just send me mail, i'll help to decouple Form and FormPage to make subclassing easier. I am quite busy until i leave for guatemala to get everything finished.

great. thank you. I will get in touch with you after the conference.

q1: yes. this is possible. one can define a policy with the "role" creator, such that only the creator (and the admin) has rights to perform certain operations. This is independent of formpages and works for all kind of of xowiki objects. We did last year the conference registration for the Vienna OpenACS/DotLrn conference based on that.

q2: currently, one can subscribe either the whole xowiki instance (via package_id) or a category (subscribe to changes for pages having this category). It should be possible with moderate effort to add subscription for single items. Having this, it should be technically possible to auto-subscribe admins and owners for certain items. But both steps are not implemented, maybe there are better approaches to reach this effect.

There exists a family of architectural styles and approaches using attribute based selection, which are often used in connection with event based systems (e.g. middleware). In such system, one can define types of events that trigger arbitrary actions for observed (managed) objects, where attributes are used as a selection mechanism of a monitor (quite similar to an access control monitor). Such approaches are frequently discussed in the area of publish/subscribe systems and event-based middleware (see e.g. http://www.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/topics/middleware/em&file=EM.xml&xsl=article.xsl
http://cocoon.ifs.tuwien.ac.at/pub/debs/debs2007.pdf
http://portal.acm.org/citation.cfm?id=966636).

xowiki policies make only one step in this direction, one could certainly bind some actions to the identified situations. However, this is a limited form (maybe still useful), where the publishing part (one should be able to publish event types, for which users could subscribe) and the user subscription part are missing. one could probably use the notification part of OpenACS.

whatever the error is, it is not related with policy3. It might be a consequence of an earlier error, or maybe of a package reload. If you find a way to reproduce the error, please report.

Hi Nima,

the test cases appear to be correct in the head version. In the case of the table view, with "@table:a1,a2", it says first "yes" "no" and then "no" "no". I am not sure if it is worth backporting the fixes from the head version to oacs-5-3, since it is in some respects already quite different, and i have a very tough schedule until i leave on monday morning (including the materials for the conference).

The plan is to produce another stable version from head in the oacs-5-4 branch, which will have these problems fixed.

The permission stuff is simple to fix, there were no rules for Form in policy2 and policy3; see:
http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/tcl/package-procs.tcl?r1=1.94&r2=1.95
One is only allowed to call methods if a policy permits it. Removing entries from there (or not adding it) makes methods unaccessible via the url interface.

We get a similar error in an OpenACS 5.3 (oracle) checked out from CVS

can't read "policy": no such variable
while executing
"$policy defined_methods Package"
(procedure "resolve_page" line 9)
::950 ::xowiki::Package->resolve_page
invoked from within
"my resolve_page [my set object] method"
(procedure "invoke" line 6)
::950 ::xowiki::Package->invoke
invoked from within
"::$package_id invoke -method $m"
invoked from within
"::$package_id reply_to_user [::$package_id invoke -method $m]"
(file "/web/devext/packages/xowiki/www/index.vuh" line 21)
invoked from within
"source [ad_conn file]"
(procedure "rp_handle_tcl_request" line 3)
invoked from within
"$handler"
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
$handler
} ad_script_abort val {
# do nothing
}"
invoked from within
"rp_serve_concrete_file [ad_conn file]"
(procedure "rp_serve_abstract_file" line 60)
invoked from within
"rp_serve_abstract_file "$root/$path""
("uplevel" body line 2)
invoked from within
"uplevel $code"
invoked from within
"ad_try {
rp_serve_abstract_file "$root/$path"
set tcl_url2file([ad_conn url]) [ad_conn file]
set tcl_url2path_info..."

the versions are the ones from CVS oacs-5-3:

xotcl-core 0.56.3
xowiki 0.60.3

we have the error in aproximately half of the clicks within xowiki pages so we can't reproduce it always but very often.
It's not always in resolve_page, in fact more often we got it in the call procedure,

Any Ideas or any further things we should test?

thanks in advance

<include src="/packages/xowiki/lib/view" url="@url@" template_file="view-links">