Forum OpenACS Development: Re: xowiki 0.47

Collapse
13: Re: xowiki 0.47 (response to 12)
Posted by Gustaf Neumann on
these adp includes are most likely outdated. Try

{{categories -title References -tree_name *ref*}}

Collapse
16: Re: xowiki 0.47 (response to 13)
Posted by Matthew Coupe on
Hi,

I've got xowiki 0.47 and xotcl-core 0.47, these are the highest version numbers I've tried on this instance of OpenACS.

When I try uploading an image file it is not being recognised as such and is being named as follows:

en:2162054 - the 2162054 is a code and not the file name.

Whereas on version 0.37 of xowiki it would name the file:

image:images.jpg

Due to this it isn't possible to display any images uploaded. When I try to rename it to image:**** it still appends the locale at the beginning of the filename.

Any ideas?

Cheers,
Matthew

Collapse
17: Re: xowiki 0.47 (response to 16)
Posted by Gustaf Neumann on
Hmm, most likely, you need: http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/tcl/xowiki-form-procs.tcl?r1=1.32&r2=1.33
Try the version of xowiki and xotcl-core of March 2, 2007, this was at the begin of a week with little changes.

Seems time to invent some tagging to make it easier to check out stable versions, when i am doing more substantial changes in cvs head.

Collapse
18: Re: xowiki 0.47 (response to 17)
Posted by Matthew Coupe on
Hi Gustaf,

Thanks for the hint. I tried the version from cvs of March 2nd using the following.

cvs -z3 -d:pserver:anonymous@cvs.openacs.org:/cvsroot co -D 2007-03-03 openacs-4/packages/xotcl-core
(& xowiki)

It fixed the image uploading problem but there seems to be one small problem with the podcast generation:

can't read "name": no such variable
::xotcl::__#q ::xotcl::Object->set
invoked from within
"$data set name"
(procedure "get_uploaded_file" line 16)
::xowiki::f1 ::xowiki::FileForm->get_uploaded_file
invoked from within
"my get_uploaded_file"
(procedure "::xowiki::validate_file" line 3)
invoked from within
"::xowiki::validate_file"
("uplevel" body line 1)
(procedure "ad_form" line 1)
invoked from within
"ad_form -extend -name [my name] -validate [my validate] -new_data $new_data -edit_data $edit_data -on_submit $on_submit -new_request $new_request -..."
(procedure "generate" line 45)
::xowiki::f1 ::Generic::Form->generate
invoked from within
"::xowiki::f1 generate -export [list [list return_url $return_url]]"
(procedure "edit" line 57)
::xotcl::__#q ::xowiki::Page->edit
invoked from within
"$page edit -new true -autoname $autoname"
(procedure "edit-new" line 7)
::1978766 ::xowiki::Package->edit-new
invoked from within
"$object $method"
(procedure "call" line 7)
::1978766 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 8)
::1978766 ::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 "/var/lib/aolserver/nccedudotlrn/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..."

I'm so close I can almost touch it!!

Thanks again,
Matthew

Collapse
19: Re: xowiki 0.47 (response to 18)
Posted by Gustaf Neumann on
looks like you went to admin, clicked on "Add Podcast Item" and you pressed enter (OK) without adding anything. Well, the validator for uploaded files was broken (fixed in the current version). The logic of the validator is a little tricky, since on revisions, one is not required to provide a file fore each revision, it is as well possible to reuse the uploaded file and edit just the meta-data.

I have installed the version from the date. Uploading podcast items with provided entries seems to work fine.

Collapse
20: Re: xowiki 0.47 (response to 19)
Posted by Matthew Coupe on
Thanks for your relpy gustaf,

I tried it again uploading a file and it seemed to work fine.

I think I was trying to run before I could walk...

How feasible would it be to link to a file uploaded to some other hosting service? We're looking at uploading GBs of data and don't want the additional strain on our dotLRN server. This is what I was trying to do when I got a similar message to the one above. I don't know if this is even possible with podcasting (having content hosted externally to the xml file)?

Cheers!

Collapse
21: Re: xowiki 0.47 (response to 20)
Posted by Gustaf Neumann on
if you have the background delivery activated, the additional strain for the server is very low, since no connection threads are blocked during delivery. From the organizational point of view, storing podcasts at the same place as other learning resources makes maintenance easier than storing this at different places (e.g. permissions, archiving, ....). technically, it would be possible to provide links instead of files (one should care about a simple interface and issues like cross site scripting etc. when implementing it).
Collapse
22: Re: xowiki 0.47 (response to 21)
Posted by Matthew Coupe on
Background delivery sounds interesting, I'll have a look at that. Keeping the files together is ideal but we are going to be building up a massive repository of high definition videos so it's just not feasible to keep them together.

On a different matter, I'm trying to include various package functionality within the wiki page, such as displaying a set of faqs and a chat window.

I've managed to get a couple of packages working pretty well , such as including a list of recent posts to a weblogger with links to the actual post itself, but the two mentioned above I am struggling with.

The main problem seems to be that the pages I am trying to include require a query string variable so each time I try to include them like this:

{{adp /packages/faq/www/one-faq {faq_id 2474310}}}

I get a message like

We had a problem with your input:

You must supply a value for faq_id

Please back up using your browser, correct the above error, and resubmit your entry.

Thank you.

Is it possible to pass query string variables through an adp include or will I need to edit the faq and chat packages themselves?

cheers