Forum OpenACS Development: Re: XoWiki 0.33 -- storing files in the xowiki instance

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!