Forum OpenACS Development: XoWiki 0.30

Collapse
Posted by Gustaf Neumann on
i am glad to announce xowiki 0.30. This is a major overhaul of the xowiki package, most likely the biggest change so far. As a result, the package is much more object oriented than it was before and it can be used in a more flexible manner. During development most of the functionality broke, but i hope that i have removed most bugs. The major changes relative to the last release are:

  • oo interface to objects:

    in order to perform operations on objects, XoWiki uses now in the oo style
    methods of these objects (in contrary to use global functions designed to work on
    all kind of objects). For example, in order to edit a page called en:test, one can
    call now a method edit of test instead of calling the global www/edit.tcl.
    global calls (such as getting the rss content of an XoWiki instance) are
    methods of the package object (see below)

  • symbolic interface to objects

    XoWiki uses now on each possible place object names instead of object ids
    as external interface. Per default media wiki style names (underscore instead of spaces)
    are used (subst_blank_in_name is now per default 1).
    This is closely related to the point above.

  • more beautiful links:

    Pages can be references now without the /pages/ prefix. instead of
    xowiki/pages/en/my_page
    one can use now
    xowiki/en/my_page
    The only current hard limitation is that pages are not allowed to start with "admin/"

  • configuration management

    XoWiki supports now a 2-level configuration. In addition to the
    configuration over the folder object (see documentation), package
    parameters can be used. The configuration over the folder object
    have the advantage to allow computed values, etc. the package parameters
    are more user-friendly for non-programmers. The entries in the folder object
    take precedence over the values from the package parameters. The following
    package parameters are currently supported

    index_page
    weblog_page
    subst_blank_in_name
    use_gc (use general comments)
    use_tags (use tags, e.g. allow the user to tag pages)
    use_user_tracking (track usage of users such as last visited pages etc.)

    the last three package parameters allow to turn off various xowiki
    features.

  • inclusion of XoWiki pages in other applications:

    In addition to the approach described in
    http://www.openacs.org/forums/message-view?message%5fid=459480
    one can use now symbolic names for the includes as well without any
    need to determine a package_id or item_id on the including side
       <master>
       <property name="title">@page_title;noquote@</property>
       <property name="context">@context;noquote@</property>
        bla bla bla...
       <include src="/packages/xowiki/lib/view" url="/xowiki/en/my_page">
  • new class ::xowiki::Package to handle all package-specific calls
    and to capture the package specific information

  • policy management

    XoWiki allows to define per instance different policies concerning
    rights on operations callable over the web. Only methods that are covered by an policy are callable over the web.
    A policy can contain context dependent permissions. The
    following definition is the default policy for XoWiki.

    It says for example, that the method reindex of the package
    requires admin rights on the package id, or that edit of
    ordinary pages requires write permissions, whereas an
    edit operation of an instance of ::xowiki::Object requires admin rights.

    The policy is used for guarding the calls as well as
    for deciding what links should be presented to the users.
       Policy policy1 -contains {
        Class Package -array set require_permission {
          reindex            {{id admin}}
          rss                none
          edit-new           {{{has_class ::xowiki::Object} id admin} {id create}}
        }
        Class Page -array set require_permission {
          view               {{package_id read}}
          revisions          {{package_id write}}
          edit               {{package_id write}}
          make-live-revision {{package_id write}}
          delete-revision    {{package_id admin}}
          delete             {{package_id admin}}
          save-tags          login
          popular-tags       login
        }
        Class Object -array set require_permission {
          edit               {{package_id admin}}
        }
      }
  • numerous other changes
    * default page is now .../admin/list
    * improved admin pages (containing date, sortable, warnings)
    * update script to get rid of orphan entries created by content_item__new(),
    when title is provided

    The documentation should be updated during the next days.

Collapse
2: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
Gustaf

XoWiki 0.30 seems to break pretty badly on upgrade. If I visit the index page with an XoWiki Object defined in the xowiki package I get something like this:

invalid command name "292676"
    while executing
"$folder_id get_payload index_page"
    invoked from within
"if {![info exists object_type]} {
  set index_page [$folder_id get_payload index_page]
  if {$index_page ne ""} {
    set item_id [Generic::CrItem loo..."
    ("uplevel" body line 36)
    invoked from within
"uplevel {
ad_page_contract {
  This is the main page for the package.  It displays all entries
  provides links to create, edit and delete these

I just did someting and it seems to work,

I copied back the XOwiki 0.28 code, restarted aolserver, and it still didn't work. So I copied the 0.30 code back, and without restarting, now it works.

I restarted again, and i can view pages, but not edit them:

can't read "edit_form_page_title": no such variable
    while executing
"lang::util::localize ${edit_form_page_title}"
    invoked from within
"set __adp_properties(title) "[lang::util::localize ${edit_form_page_title}]""
    ("uplevel" body line 5)
    invoked from within
"uplevel {
set __adp_output ""
Collapse
6: Re: Re: XoWiki 0.30 (response to 2)
Posted by Gustaf Neumann on
dave, how did you make the cvs update? The messages above are from index.tcl + index.adp, which are removed from the cvs in 0.30. everything is controlled via index.vuh. a cvs update should take care of this....

-gustaf

Collapse
50: Re: XoWiki 0.30 (response to 2)
Posted by Ryan Gallimore on
Did you work out any fix for this? - I'm seeing the same thing on xowiki 0.36.

invalid command name "292676"

while executing

"$folder_id get_payload index_page"

invoked from within

"if {![info exists object_type]} {

set index_page [$folder_id get_payload index_page]

if {$index_page ne ""} {

set item_id [Generic::CrItem loo..."

("uplevel" body line 36)

invoked from within

"uplevel {

ad_page_contract {

This is the main page for the package. It displays all entries

provides links to create, edit and delete these

Collapse
51: Re: XoWiki 0.30 (response to 50)
Posted by Stan Kaufman on
Ryan, this happens if you haven't upgraded xotcl-core to the latest version. (It may happen for other reasons, but upgrading *both* to the latest version works for me.) Make certain you've got xowiki 0.36 and xotcl-core 0.43, restart your server, and all should be well.
Collapse
52: Re: XoWiki 0.30 (response to 51)
Posted by Ryan Gallimore on
Hi Stan, I have upgraded both as per the dependencies, but no luck. Is there another solution you can offer? Thanks.
Collapse
53: Re: XoWiki 0.30 (response to 52)
Posted by Stan Kaufman on
Hmm...sounds to me as if you must still have some cruft left over from the earlier versions. How did you upgrade? Did you cvs update the existing package directories? Try deleting the old packages and then getting a fresh checkout of each. And make certain to restart the server. No good ideas beyond those; the code base in the two packages works just fine here on an oacs-5-2 system, so I don't think this is a problem with Gustaf's work.
Collapse
54: Re: XoWiki 0.30 (response to 53)
Posted by Ryan Gallimore on
Thanks, Stan. Although I had xotcl-core 0.43 and xowiki 0.36 installed, re-checking these out and restarting is now working for me. Thanks.
Collapse
55: Re: XoWiki 0.30 (response to 54)
Posted by Stan Kaufman on
Glad to know you're running. I think this must be some cvs weirdness. "cvs update -Pd" doesn't always seem really to update everything somehow. It's a mystery.
Collapse
3: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
I tried another site of mine

First visit to index page of xowiki instance after upgrade and restart:

    while executing
"self args"
    (procedure "condition" line 7)
    ::59744 ::xowiki::Package->condition
    invoked from within
"59744 condition edit-new has_class ::xowiki::Object"
    ("eval" body line 1)
    invoked from within
"eval $object condition $method $condition"
    ("3" arm line 2)
    invoked from within
"switch [llength $cond_permission] {
	    3 {foreach {condition attribute privilege} $cond_permission break
	      if {[eval $object condition $method ..."
    (procedure "permission_p" line 14)
    ::xowiki::policy1 ::xowiki::Policy->permission_p
    invoked from within
"::xowiki::policy1 permission_p 59744 edit-new"
    ::59744 ::xowiki::Package->permission_p
    invoked from within
"$package_id permission_p $object $method"
    (procedure "make_link" line 12)
    ::59752 ::xowiki::Page->make_link
    invoked from within
"my make_link $package_id edit-new object_type"
    (procedure "view" line 65)
    ::59752 ::xowiki::Page->view
    invoked from within
"$object $method"
    (procedure "call" line 6)
    ::59744 ::xowiki::Package->call
    invoked from within
"my call $policy $page $method"
    (procedure "invoke" line 23)
    ::59744 ::xowiki::Package->invoke
    invoked from within
"$Package invoke -method $m"
    invoked from within
"ns_return 200 text/html [$Package invoke -method $m]"
    (file "/home/mgh/openacs/packages/xowiki/www/index.vuh" line 17)
    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

I would debug it if I had any idea where to look :)

Collapse
5: Re: Re: XoWiki 0.30 (response to 3)
Posted by Gustaf Neumann on
dave: the "self args" problem: seems that you are using an xotcl version 1.3.8 or earlier. i would recommend xotcl 1.4.0.
quick install notes: https://openacs.org/xowiki/pages/en/xotcl-core
Collapse
4: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
I upgraded xotcl-core and xowiki to the latest on HEAD at the same time. If I copy the code back from the previous versions of both xotcl-core and xowiki, it starts working again.

I definitely needed to revert xotcl-core.

It appears xotcl-core is not backwards compatible, the xowiki code from previous versions doesn't work with the latest xotcl-core (AFAICT)

Any ideas?

Collapse
7: XoWiki 0.31 (response to 1)
Posted by Gustaf Neumann on
cvs head contains now xowiki 0.31. The major new feature is search per instance, which can be activated from the xowiki command bar. It requires search from 5.3 or an update of search from 5.2.3 to work, otherwise, it will perform always a non-restricted global search; the new search support should lead to much better search results than in previous versions (don't index every revision, use higher weights for bold xowiki content).
Collapse
8: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
Gustaf,

Great work.

Two issues we found testing:

1) If you have existing pages with spaces in the names and upgrade the links to those pages can't be resolved because the resolver converts the spaces to underscores. We fixed by renaming the pages since new pages automatically are converted to underscores.

2) In renderng the links a link like this [[A Page Name]] will resolve to A_Page_Name with link text of A_Page_Name. I commented out line 728 in xowiki-procs.tcl to keep the original link as the link text. This way the editor can type the nice name, and get directed to the correct page, without having to add a seperate label for the link.

We are interested in either applying 2 or adding an additional option, if you think that should not be the default behavior.

Collapse
9: Re: Re: XoWiki 0.30 (response to 8)
Posted by Dave Bauer on
One other issue.

If you do not use subst_blank_in_name and allow spaces in names and URLs there is a bug

around line 548 in xowiki-procs.tcl

if {$granted} {
if {[$object istype ::xowiki::Package]} {
set base [$package_id package_url]
if {[info exists url]} {
return [uplevel export_vars -base $base$url [list $args]]
} else {
lappend args [list $method 1]
return [uplevel export_vars -base $base [list $args]]
}
} elseif {[$object istype ::xowiki::Page]} {
set base [$package_id url]
lappend args [list m $method]
return [uplevel export_vars -base $base [list $args]]
}

I cahnges the $base variable referece to \"$base\" to quote the value of $base (also did $base$url)

There is still an issue when creating the edit form if you use the [ or ] characters in the name, it is trying to execute it as a tcl proc. I could not figure out where to apply the proper escaping in that.

We probably should disallow [ and ] in names/urls anyway, but someone might also use it in a title, and the same issue occurs.

Collapse
10: Re: XoWiki 0.30 (response to 1)
Posted by Gustaf Neumann on
issue 1: it is a problem when subst_blank is turned on and off with pre-existing pages. xowiki does not change all names automatically when the flag is changed, since the mapping is not bijective. If the flag is turned on, editing the page will automatically translate spaces into underscores in the name of this page; no manual renaming is required.

issue 2: doing so will ulgify typed links (such as glossary links). The right thing is to use another variable normalized_name for the result of the normalizing method and use stripped_name for the label and normalized_name in the arguments of the link object.

issue 3: right. the better fix is to use list around the base argument of export_vars (3 times). this allows as well square brackets.

I'll polish the current work with the File class in xowiki and commit this together in the next few days.

-gustaf

Collapse
Posted by Dave Bauer on
If we delete a page, but there are links in another xowiki page, when you visit the page with the link an error like this occurs:

Database operation "dml" failed (exception ERROR, "ERROR:  insert or update on table "xowiki_references" violates foreign key constraint "$1"
DETAIL:  Key (reference)=(331757) is not present in table "cr_items".
")

ERROR: insert or update on table "xowiki_references" violates foreign key constraint "$1" DETAIL: Key (reference)=(331757) is not present in table "cr_items".

The ::Generic::CrItem lookup -name [my name] -parent_id [my folder_id]

call in link-procs.tcl is somehow returning an item_id that is no longer in cr_items.

I tried the call from the ds/shell and it returned 0 so I don't understand how this is happening. Any help is appreciated!

Collapse
Posted by Gustaf Neumann on
Just to be sure: you create a page p1, then a page p2 with a reference to p1, and you view p2. Then you delete p1 and view p2 again, you get the error. Seems, i have accidentally fixed this problem while working on xowiki::File.

If you need the fix soon, i can commit the current snapshot, otherwise i need a little time for polishing [[image:dave.png]] and [[file:docu.pdf]]. In the current snapshort, binary files are sometimes altered during download...

No need for a hasty commit Gustaf. We will just avoid deleting files till you have time for the polish (restarting the server fixed the problem for now).

I have an unrelated question about permission granularity. We have a need to be able to add specific permissions for individual pages through the UI.

There are many use cases that come to mind, but the one that is relevant to us right now has to do with wanting to hide certain pages from certain users for an internal study we are planning. A more general use case is wanting to protect a controversial page from general edit.

What are your plans in this direction? How should we implement this?

Thanks,
Carl

P.S. We are benefiting greatly from your work.

I am not sure, if "hiding pages" and "protecting pages" is the same issue. Hiding pages is a rather workflow issue, saying when a page should be released to the "public", expressing a certain state of a page, while protecting certain pages is clearly a permission issue. permissions are quite slow in openacs, permissions on the object level are not so nice for caching either (compared to permissions on the package_ids or folder_ids). The policy are going into this direction, athough they have no userinterface yet. i will think about this...

Note, that this effects rss + weblog + search + visibility of links (references between pages) as well. The easiest approach seems to me currently to provide a separate xowiki instance for the "internal study" and merge these pages later into the public set when appropriate. import/export of xowiki can be easily extended to work between xowiki instances.

Collapse
Posted by Gustaf Neumann on
Hi Carl,

i have just committed a small experimental enhancement to xowiki 0.36. The new ::xowiki::policy3 allows for checking of individual pages (policy 1 and 2 check only rights on the package). When policy 3 is activated the admin page shows an additional column for managing permissions of individual pages. The aggregating views don't evaluate the
permissions for the time being.

This approach is already fine for protecting individual pages (prohibiting edits, no problems with aggregations), but i am not sure whether this is the right approach to hide e.g. work in progress. Permission checking is quite expensive in openacs. Checking on the package level scales much better, since this is much better for caching, when many user and many pages are involved. Checking on instance level needs a space of packages * users * privileges. For checking on instance level, the needed space is much larger (objects * users * privileges). Furthermore, caching does not work well, since the probability that the same user e.g. reads the same object twice in a session is much smaller the that the same user reads two different objects form the same package in a session.

In learn@wu, we are using an "active" flag, which hides pages from non-admins. This flag can be efficiently checked in all sql queries with more or less no extra cost.

Btw, the policy manager allows as well to use for certain operations on certain pages mixed kinds of checking. Depending on the object type or a predicate satisfiable from the page instance one can use for certain operations package level or instance level checking.

Below is for reference policy3. It differs from policy2 essentially by using the attribute item_id instead of package_id for checking. It can be activated form the package parameter page (conveniently reachable from the admin pages).

best regards
-gustaf


   Policy policy3 -contains {
     #
     # we require side wide admin rights for deletions
     # we perform checking on item_ids for pages.
     #
  
     Class Package -array set require_permission {
       reindex {{id admin}}
       rss none
       delete swa
       edit-new {{{has_class ::xowiki::Object} id admin} {id create}}
     }
  
     Class Page -array set require_permission {
       view {{item_id read}}
       revisions {{item_id write}}
       edit {{item_id write}}
       make-live-revision {{item_id write}}
       delete-revision swa
       delete swa
       save-tags login
       popular-tags login
     }
  
     Class Object -array set require_permission {
       edit {{package_id admin}}
     }
     Class File -array set require_permission {
       download {{package_id read}}
     }
   }

Collapse
Posted by Carl Robert Blesius on
Excellent! There are many cases for page based permissions (a few of which I have already experienced on our installation).

I will try it out while you are away. With your guidance I would like to refine this feature so it is flexible and works well for sites with heavy load like yours.

Collapse
Posted by Prem Thomas on

Gustaf,

I'm using xowiki 0.38 and xotcl-core 0.45 and implemented security policy 3 to set write permissions for individual pages. This works fine, but I had a problem with read permissions. All the pages on this wiki instance allow public reading without login, the intended effect. When I switch from security policy 1 to either 2 or 3, the public can no longer read the pages; login is required. I double checked the permission using the lock icon in the Administration section of xowiki and read by the public is enabled; however, I still get the login page on attempted read.

I changed the view line in policy 3 in package-procs.tcl:

Class Page -array set require_permission {
view none
...


and this allowed public reading. However, this removes all ability to limit access to other pages. Is there another way to accomplish this?

Also, perhaps because of caching, changes to the tcl code in the file above, were not reflected in the site unless I restarted AOLserver.

Thank you for all the work you've put into this very useful package.

Collapse
Posted by Gustaf Neumann on
permission checked forced the user to login for all checks based on object ids. I have changed this in a way that it first checks whether the privilege was granted to the public, and if not, it requires a login. This is more costly, but the right thing.

please check out from CVS head.

Collapse
Posted by Prem Thomas on
Thanks, Gustaf. Checked out xowiki from head and tried it, but got the following error which I think is originating from xowiki-callback-procs.tcl, line 66

invalid command name "::xowiki::Object"
    while executing
"::xowiki::Object fetch_object -object ::$folder_id -item_id $item_id"
    (procedure "require_folder_object" line 24)
    ::833 ::xowiki::Package->require_folder_object
    invoked from within
"my require_folder_object"
    (procedure "init" line 5)
    ::833 ::xowiki::Package->init
    ::xowiki::Package ::xotcl::Class->create
    invoked from within
"my create ::$package_id -url $url"
    (procedure "require" line 8)
    ::xowiki::Package ::xo::PackageMgr->require
    invoked from within
"my require -url $url $package_id"
    (procedure "initialize" line 21)
    ::xowiki::Package ::xo::PackageMgr->initialize
    invoked from within
"::xowiki::Package initialize -ad_doc {

  This is the resolver for this package. It turns a request into
  an object and executes the object with the ..."
    (file "/usr/local/share/topaz/packages/xowiki/www/index.vuh" line 2)
    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..."

Collapse
Posted by Gustaf Neumann on
Since I got no fast feedback from thomas and i am leaving tomorrow for a short vacation, a short diagnosis, that might help some other people as well:

If one sees errors like this, please check the following items

  • Make sure, that acs-bootstrap-installer/bootstrap.tcl is up to date (it should include loading of the xotcl-core *init-files.
  • on cvs updates, it seems to happen that not all files are updated correctly. In the case of Thomas, it looks like the file xotcl-core/tcl/05-db-procs.tcl was missing.
The new versions of xowiki (in CVS head) need in most cases the new versions of xotcl-core from cvs head as well (it has the dependencies set). The dependencies are only checked on upgrades. If one simply updates the files, and reloads it, the dependencies are not checked...
Collapse
Posted by Prem Thomas on

As Gustaf notes above, the fix for my problem involved cvs updates of two packages, xotcl-core and acs-bootstrap-installer, on which xowiki depends. With this done, the error above disappeared.

Security policy3 for xowiki now works perfectly with permission setting on individual pages; pages with public read permission now do not ask for login prior to read.

Collapse
13: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
Gustaf, that explains the problem precisely.
Collapse
15: Re: XoWiki 0.30 (response to 1)
Posted by Dave Bauer on
I want to also say thank you for all your hard work on XoWiki. To make it clear, I am certainly not complaining when I find issues, and working with XoWiki I am learning alot!

I am posting here to open discussion and make sure, if I find an issue, that the correct fix is applied. Luckily XoWiki has a very active package maintainer in Gustaf and we all appreciate it.

Collapse
16: XoWiki 0.32 (response to 1)
Posted by Gustaf Neumann on
XoWiki 0.32 is now in CVS head. XoWiki and the accompanying xotcl-core versions support now the storage_type file. One can now store files and images in xowiki folders and reference these in mediawiki like style. Therefore, images can be added now even without xinha and without the image tag. For example, the following text will include an image and a link to file within a wiki page
... here is a nice logo [[image:DotLrnLogo.gif|Logo of .LRN]] and the printed documentation [[file:documentation.pdf|The .LRN User Handbook]] ....
If theses object do not exist, xowiki renders the missing parts with the usual brackets, which can be used to click on to add (upload) the files.

This is implemented via a new class ::xowiki::File, a subclass of ::xowiki::Page. Therefore it reuses most of its properties. Files and images "know", where they are included (which pages reference them) and provide back-links to the including pages, they can be used in categories, they can be tagged (like in de.icio.us), they are contained in the rss or the weblog, they are included in the search (e.g. pictures are indexed via their title and description)

In later versions of xotcl, it should be possible to export and import files like other pages as well to transfer content easier between servers.

I was fighting quite long with a very strange problem, which is apparently Mac OS X specific: While the download with most of my test files (binary or not) worked without any problems, one .pdf file appeared truncated after download. While the original file size is 948130, the file had a size 143360 after download, although the content length in the http headers was correct. i certainly expected the bug to be somewhere in the newly implemented code of xowiki.

It took me a while to figure out, that the same happens with file-store as well. Interesting enough, the file download works correctly with bgdelivery. The problem turned out to be a configure problem, which sets HAVE_POLL to 1, where POLL does not seem to work together with aolserver (4.0.10). Compiling aolserver 4.0.10 with -DHAVE_POLL=0 solves the problem. Where available, xowiki will deliver files with bgdelivery.

Collapse
18: Re: XoWiki 0.30 (response to 1)
Posted by Malte Sussdorff on
Only a minor thing, but on openacs.org at least, when editing an entry, I do not have a link which would pop up the special xowiki syntax (the editing part of the XoWIKI documentation or maybe an XoWIKI Editing Wiki (where we could add more tips and tricks on editing?)
Collapse
19: XoWiki 0.32 (response to 1)
Posted by Gustaf Neumann on
I have updated the documentation in http://media.wu-wien.ac.at/download/xowiki-doc/ to reflect most of the current state. It is far from being really good, but certainly better than what we had before...
Collapse
21: Re: XoWiki 0.32 (response to 19)
Posted by Matthew Burke on
Wasn't sure this was worth a new thread:

I've been trying to upgrade XoWiki and have had an afternoon of no luck.

I'm running OpenACS 5.2.3b2 with XoTcl 1.4.0 and Postgresql 7.4.x. Starting from a brand new install, I grabbed the XoTcl Core 0.41 apm and the Xowiki 0.32 apm, installed them and get the following error when I go to /xowiki for the first time.

I nuked every thing and tried previous versions of xotcl-core and xowiki and got an error that looked like a mal-formed SQL statement when trying to create the package.

Any thoughts?

Thanks,

Matt

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

ERROR: insert or update on table "acs_objects" violates foreign key constraint "acs_objects_package_id_fk"
DETAIL: Key (package_id)=(0) is not present in table "apm_packages".

SQL: select content_item__new('::741',741,null,null,null,'506',null,null, 'content_item','::xowiki::Object',null,NULL,NULL, NULL,null,null,null,'f','text', 0)
while executing
"ns_pg_bind 0or1row nsdb0 { select content_item__new(:name,741,null,null,null,:creation_user,null,null, 'content_item',:object_type,null,:description,:..."
("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 0or1row $db $full_name $sql"
invoked from within
"set selection [db_exec 0or1row $db $full_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 0or1row $db $full_name $sql]
}"
(procedure "db_string" line 8)
invoked from within
"db_string insert_item " select content_item__new(:name,$parent_id,null,null,null,:creation_user,null,null, 'content_item',:object_type,null,:descripti..."
invoked from within
"set item_id [db_string insert_item " select content_item__new(:name,$parent_id,null,null,null,:creation_user,null,null, 'content_item',:object_type,nu..."
("uplevel" body line 5)
invoked from within
"uplevel 1 $transaction_code "
(procedure "db_transaction" line 1)
invoked from within
"db_transaction {
$__class instvar storage_type object_type
$__class folder_type -folder_id $parent_id register
db_dml lock_objects "..."
(procedure "save_new" line 23)
invoked from within
"next"
(procedure "save_new" line 3)
::741 ::Generic::CrCache::Item->save_new
invoked from within
"::$folder_id save_new"
(procedure "require_folder_object" line 34)
::734 ::xowiki::Package->require_folder_object
invoked from within
"my require_folder_object"
(procedure "init" line 7)
::734 ::xowiki::Package->init
::xowiki::Package ::xotcl::Class->create
invoked from within
"::xowiki::Package create ::$package_id -folder_id $folder_id"
invoked from within
"set Package [::xowiki::Package create ::$package_id -folder_id $folder_id]"
(file "/usr/local/www/bitdojo.org-dev/packages/xowiki/www/index.vuh" line 15)
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..."

Collapse
22: Re: Re: XoWiki 0.32 (response to 21)
Posted by Gustaf Neumann on
Mathew,

xowiki 0.33, available since sunday fixes the problem you are mentioning. it is not a malformed SQL, but a 0 valued package_id. The last line of my announcement of 0.33 references the problem you are observing with 0.32.

Collapse
23: Re: Re: Re: XoWiki 0.32 (response to 22)
Posted by Matthew Burke on
Gustaf,

Thanks! -- as I embarassedly write on the blackboard 100 times "I will make sure to _thoroughly_ read threads before posting"

Collapse
24: Installing XoWiki 0.33 (response to 23)
Posted by Matthew Burke on
Ok, not so fast.... :)

I grabbed the head (made sure it was 0.33). Dropped the database, installed from scratch again. Reread this whole thread (cross my fingers I'm not overlooking anything obvious) and installed XoWiki. I get the following:

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

SQL: insert into xowiki_objecti (item_id,revision_id,creation_user,title,description,mime_type,nls_language,text,page_title,creator) values ('744','745','506','::743',NULL,NULL,NULL,'# this is the payload of the folder object

set index_page "en:index"
',NULL,NULL)
while executing
"ns_pg_bind 0or1row nsdb0 {insert into xowiki_objecti (item_id,revision_id,creation_user,title,description,mime_type,nls_language,text,page_title,creat..."
("uplevel" body line 1)
invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql]"
("postgresql" arm line 2)

I've snipped the error listing.

Matt

Collapse
Posted by Stan Kaufman on
Matthew, did you get xotcl-core from HEAD, too? I'm guessing not. Make sure you're using xotcl-core 0.41 with xowiki 0.33. I've just installed without errors both on an otherwise vanilla oacs-5-2 checkout.
Collapse
Posted by Gustaf Neumann on
Matt, can it be that you the xotcl-core 0.41 between
Sat Aug 5 20:38:24 2006 UTC and
Sat Aug 5 20:39:28 2006 UTC?

xotcl-core checks, whether oacs 5.3.0d2 or newer is installed and chooses the appropriate database-operation, unless it is stated differently, as on my notebook.

For 1 minute an 4 seconds, a incorrect version was in cvs:
http://cvs.openacs.org/cvs/openacs-4/packages/xotcl-core/tcl/generic-procs.tcl?r1=1.21&r2=1.22

maybe an update solves the problem....

Speaking of hardware, the new Mac Pros presented just now at WWDC sound like great machines for OpenACS (4 cores...)

Collapse
Posted by Matthew Burke on
I don't think I grabbed it during the unlicky four minutes, but I tried grabbing head again, and did a clean install and it works. Well, it works more than before, but still not quite. I get the following error now when I edit pages or attempt to create new pages.

wrong # args: should be "ns_cache names cache"
while executing
"ns_cache names xowiki_cache link-*-$folder_id"
(procedure "update_references" line 17)
::xowiki::f1 ::xowiki::WikiForm->update_references
invoked from within
"my update_references"
(procedure "new_data" line 7)
::xowiki::f1 ::xowiki::WikiForm->new_data
invoked from within
"::xowiki::f1 new_data"
invoked from within
"set item_id [::xowiki::f1 new_data]"
("uplevel" body line 1)
invoked from within

Next thoughts? I've got the latest AOLserver FreeBSD package so I'm not convinced it's an obsolete nscache module, but I don't have any other ideas.

Matt

Collapse
Posted by Gustaf Neumann on
This looks like an easy problem. get a recent version of ns_cache. nscache has the syntax

ns_cache names cachename ?pattern?

since a couple of ... years (?). Get a recent version of nscache

cvs -z3 -d:pserver:mailto:anonymous@aolserver.cvs.sourceforge.net:/cvsroot/aolserver co nscache

seems, as if xowiki exercises some oacs componens more than other packages....

-gustaf

Collapse
20: XoWiki 0.33 (response to 1)
Posted by Gustaf Neumann on
XoWiki 0.33 is available and checked into CVS head.
The major changes against 0.32 are:
  • Direct inclusion of xowiki pages (using e.g. {{en:my_page}}, somewhat similar to [[en:my_page]]): Direct inclusion is significantly faster than adp inclusion, which can still be achieved via {{adp portlets/wiki {name en:my_page}}}

  • Easier provision for default xowiki pages (default index page, default weblog page). See xowiki/www/default-pages.

  • Some cleanup: removal of obsolete files, fix when mounting XoWiki the first time.
Enjoy.
Collapse
Posted by Stan Kaufman on
The latest xowiki docs indicate that images for an xowiki page no longer need to be uploaded into a file-storage instance:

Starting with XoWiki 0.32, files (e.g. pdf files) and images can be stored directly in an XoWiki instance. Prior to this, it was necessary to link to files e.g. in an OpenACS file-storage.

However, the xinha widget still puts any uploaded image into a file-storage instance. The new approach of using the xowiki instance itself -- rather than a file-storage instance -- seems to be a much cleaner solution. But there doesn't seem to be any way to do this yet.

Is this a package configuration issue? A not-yet fully implemented feature? Something else? TIA!

Stan, see the xowiki 0.32 announcement above and http://media.wu-wien.ac.at/download/xowiki-doc/
in the Editing section. In short: write in your page ... [[image:myfigure.png]] ... and you get a link to include the image (or file). This approach does not require xinha and is in some respects more safe, since no urls have to be entered by untrusted users. The images and files are "first class" xowiki objects, one can see where these image are included, can provide tags, etc.

It should be possible to write some code to add files/images via xinha to xowiki folders, but the dialogs must be changed due to the wiki style nameing conventions and different urls. This would be xowiki only.

dave is working on a image upload where images are stored as subobjects of arbitrary objects (as well xowiki pages), which have the property that they will be deleted when the parent object is deleted.

Gustaf, thanks for your prompt reply -- as always! What I'm actually trying to do is to create xowiki pages (and their embedded images) programmatically as part of migrating 3.x sites to 5.x. The interactive mechanism you point out isn't exactly what I want, but the code that underlies it is, so thanks for the clarification!
If the image uses the xowiki page as the parent, it will automatically be deleted if you use content::item::delete as this deletes the children of an item as well. At least luckily this is the behaviour I have seen in our glossar package when using content::item::delete 😊. So I'm not sure why you need dave's image upload.
... If the image uses the xowiki page as the parent...
yes, but it does not. This would not be a trivial change, since the name lookup wouldn't work (among other things).
Gustaf, I've been playing with your new image-embedding mechanism, and I've run into problems for which I've filed a bug report. The problem seems to be with the way xotcl caches object data -- I think; I'm still struggling to grok how code gets called and data get passed in this new world of xotcl. 😉 Thanks in advance for any pointers!
Stan, i have notice the error as well. if everything goes well, i hope to be able to commit 0.34 later today.
Collapse
Posted by Stan Kaufman on
It appears that the form_parameter variable of ::xowiki::Package isn't getting reset.

In /xowiki/tcl/package-procs.tcl, the ::xowiki::Package create instproc was commented out for some reason, so when a new ::xowiki::Package was getting created in /xowiki/www/index.vuh, it wasn't getting created cleanly/correctly.

Restoring that instproc seems to do the trick -- at least the image object gets created and the page will display once you navigate back to it. However, the image object creation step return an error from the ::xowiki::Link::image render proc:

 [08/Aug/2006:15:00:48][6355.1029776][-conn:oacs52::0] Error: POST http://127.0.0.1:8052/pages/?object%5ftype=%3a%3axowiki%3a%3aFile&edit%2dnew=1&return%5furl=%2fpages%2fen%2fTest
referred by "http://127.0.0.1:8052/pages/?last%5fpage%5fid=11519&object%5ftype=%3a%3axowiki%3a%3aFile&name=image%3atest10%2ejpg&edit%2dnew=1&title=test10%2ejpg&return%5furl=%2fpages%2fen%2fTest"
invalid command name "::xotcl"
    while executing
"$page lappend references [list $item_id [my type]]"
    (procedure "render" line 8)
    ::xotcl::__#35 ::xowiki::Link::image->render
    invoked from within
"$l render"
    (procedure "get_content" line 23)
    ::xotcl::__#32 ::xowiki::File->get_content
    invoked from within
"my get_content"
    (procedure "render" line 11)
    ::xotcl::__#32 ::xowiki::Page->render
    invoked from within
"$data render -update_references"
    (procedure "update_references" line 8)
    ::xowiki::f1 ::xowiki::WikiForm->update_references
    invoked from within
"my update_references"
    (procedure "new_data" line 7)
    invoked from within
"next"
    (procedure "new_data" line 4)
    ::xowiki::f1 ::xowiki::FileForm->new_data
    invoked from within
"::xowiki::f1 new_data"
    invoked from within
"set item_id [::xowiki::f1 new_data]"

This looks like it's probably due to a typo, but I can't figure it out.

The problem with the ::xowiki::Link::image render instproc is that it calls [my info parent] which returns ::xotcl instead of ::xowiki::File as it should.

Since ::xowiki::Link::image is ultimately just an ::xotcl::Object, it's not clear where its parent would ever get set. In fact, [my info vars] on a link image object returns just these vars: package_id folder_id label name lang type stripped_name.

So should ::xowiki::Link have a superclass, say, ::xowiki::Object? Or does parent need to get set at initialization of an object? Or is parent something that needs to be computed via an instproc like resolve?

Gustaf, I know that you said you're going to provide a fix with a 0.34 version, but if you wouldn't mind thinking aloud here about this stuff, it would certainly help us all to understand how to work with your packages. Thanks!

Collapse
36: XoWiki 0.34 (response to 1)
Posted by Gustaf Neumann on
Well, here comes xowiki 0.34.

The most important changes are:

  • fixes for the mentioned bugs (and a few unmentioned more)

  • notifications (configurable via package_parameter)

  • some code rearrangements (e.g xowiki-callback-procs)

  • improved div handling

  • removed one more obsolete file (view.adp)

  • using objects for default pages to allow for different
    types of pages and specifying page title etc.
    (default pages are created from files in the CR on
    demand and can be altered per instance; xowiki comes
    with a default index page (xowiki/index) and weblog
    page; created for example, when someone clicks on a tag)

as always, the newest xowiki version is in cvs HEAD.

All the best -g

Collapse
37: bugs (response to 1)
Posted by Gustaf Neumann on
ok, here are the solutions for the bugs puzzle (although it is annoying to detail my bugs here:)

- form_parameter variable of ::xowiki::Package:
a wrong names was used in the instvar line,
which is responsible for resetting the variable.
these associative array in the ::xowiki::Package
are a transitional stuff, a better solution
with a connection context will come in the future.

- [my info parent] returns the parent namespace.
in an aggregation (on object contains another)
it returns the parent object (the containing object).
here is a short paper about xotcl aggregation
http://nm.wu-wien.ac.at/research/publications/sac.pdf

In some cases, the ::xowiki::Link objects where
not created in an aggregation, causing to return
::xotcl. now the Page object is passed explicitly.

-gustaf

Collapse
38: Re: bugs (response to 37)
Posted by Stan Kaufman on
Thanks again, Gustaf. I'm certainly not trying to embarrass or annoy you. I'm just trying to understand how things work! 😊
Collapse
41: XoWiki 0.35 (response to 1)
Posted by Gustaf Neumann on
XoWiki 0.35 is available in cvs HEAD.

The major changes to 0.34 are

  • optional display of used categories per page
  • notifications per categories
  • improved handling of invalid URLS in xowiki/admin/... (happens, when someone types an invalid string; 0.34 went into a redirection loop)
  • return_urls for editing xowiki pages from the admin pages
  • possibility to provide multiple categories to weblog (every displayed page has to be in all provided categories, very useful when multiple category trees are used)
  • fix for delete-all on admin pages
  • some minor css fixes
Collapse
Posted by Claudio Pasolini on
Hi Gustaf,

yesterday I did a fresh install of xotcl-core 0.42 and xowiki 0.34 and today upgraded to 0.35. In other sites I'm yet using xowiki 0.24 and the improvements are really staggering!

However, I had problems loading and retrieving files and images to and from xowiki folders. I tried loading a file in two ways:

  1. creating an ::xowiki::File and then referencing it with the new syntax [[file:myfile|My File]] from a ::xowiki::Page
  2. creating an ::xowiki::Page and a link to a non existent file with the same syntax and then clicking on the '[' to upload the file
In both cases when I view a page with a link to a file in a xowiki folder and try to follow the link the system hangs forever.

Even worst, if i put a reference to an image on a page, the page hangs and the link to the image don't shows itself.

All the rest seems to work well, and of course I can continue to use Xinha to load and reference file and images, but the new way is really more clean and simple.

Collapse
Posted by Gustaf Neumann on
Claudio,

To clarify things: i deduce from your mail, that the upload of the image went well (say [[image:DotLrnLogo.gif]], you seen the uploaded entry from the admin pages) but the view of the image (like /xowiki/image/DotLrnLogo.gif?m=download) hangs.

What operating system is the server? There is a known issue with Mac OS X (see above in the thread).

In what browser does this happen?

Do you see an error message in the log file?

Collapse
Posted by Claudio Pasolini on
Thank you for answering, Gustaf.

i deduce from your mail, that the upload of the image went well (say [[image:DotLrnLogo.gif]], you seen the uploaded entry from the admin pages) but the view of the image (like /xowiki/image/DotLrnLogo.gif?m=download) hangs

yes, I see the object from the admin pages, but when I click to view it the page hangs.

What operating system is the server? In what browser does this happen?

Linux RedHat 8.0 - Firefox 1.5.0.6

Do you see an error message in the log file?

Yes, there is an error in the log file:
invalid command name "throttle" while executing "throttle get_context"
Sorry to not have hilighted this before. Aolserver starts fine without any errors.

Collapse
Posted by Gustaf Neumann on
ok. Seems as if you have "my" the aolserver patches for bbdelivery installed, but you do not have the request monitor. I will check, to remove the dependency. for now, the code checks whether throttle is available, and does not call bgdelivery. i have not tried the change with your configuration, but the code should be fine (famous last words).

-gustaf
PS: these tests should and will go to xotcl-core

Thank you Gustaf,

installing xotcl-request-monitor fixed the problem.

i should have mentioned in my last posting, that i have already commited a patch that does not require your to have the request monitor installed. Anyhow, installing it is not a bad idea in general.

Right now, i am just changing the internals in xotcl-core to reduce the complexity and make it easier to handle the connection context in variuous situations... guess, i won't commit soon, since currently i broke everything in my setup...

all the best
-gustaf