Forum .LRN Q&A: Re: dotlrn-xowiki and xowiki-portlet available

Collapse
Posted by Eduardo Santos on
Hy Gustaff,

Thank you very much for this. I was already losing a lot of time, because one of my clients requested the same thing. I can say you saved me a lot of time, and I'm very thankful for this.

I'm still trying to install it, but I have a question: does it work on dotLRN 2.2.0? The dependencies say that it doesn't, but I really didn't want to upgrade right now. I have a large system, and upgrade it allways gives a hard time. Is there anyway I can make it work on dotLRN 2.2.0?

Collapse
Posted by Gustaf Neumann on
Eduardo,

concerning the dependencies: the two packages were built and tested against dotlrn 2.2.1. Most likely, they will work with dotlrn 2.2.0 as well. just edit the version numbers in the .info files and to match your versions. If it does, send me the numbers, and i will update in the packages.

Collapse
Posted by Eduardo Santos on
Hi Gustaf,

I checked the changes and the packages seem to work very well in dotlrn 2.2.0. Maybe you should change the number in the .info.

Collapse
Posted by Matthew Coupe on
Only just seen this, please ignore my other post.

https://openacs.org/forums/message-view?message_id=1103032

cheers

Collapse
Posted by Matthew Coupe on
I've got:
xowiki 0.47
xotcl-core 0.47
xowiki-portlet 1.0.2
dotlrn-xowiki 1.0.2
(both from CVS)
dotlrn 2.2.0

I bumped down the version number of dotlrn required to 2.2.0 to allow the install as Eduardo did.

I followed the instructions through to clicking on:

Add New Xowiki Portlet

This should add a new xowiki portlet but I get an error message as follows:

wrong # args for method 'resolve_request': valid arguments -path method_var
while executing
"::xotcl::interpretNonpositionalArgs $args"
(procedure "resolve_request" line 2)
::2475139 ::xowiki::Package->resolve_request
invoked from within
"$package_id resolve_request -path $page_name"
invoked from within
"set page_id [$package_id resolve_request -path $page_name]"
("uplevel" body line 17)
invoked from within
"uplevel {
::xowiki::Package initialize -ad_doc {
Add an element to a given portal

@author Gustaf Neumann (mailto:gustaf.neumann@wu-wien.ac.at)
@creati..."
(procedure "code::tcl::/var/lib/aolserver/dotlrndev/packages/xowiki/www/..." 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..."

Any ideas anyone?

cheers

Collapse
Posted by Eduardo Santos on
Hi Matthew,

My version numbers where the same as you have, but I couldn't see these errors. That's strange. Maybe I did something wrong that was right in the end.

Collapse
Posted by Gustaf Neumann on
hmm, you need either http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/www/admin/portal-element-add.tcl?r1=1.1&r2=1.2
or a newer version of xowiki (e.g. 0.50).

To ease release management, we will store a "stable version" of xowiki in the oacs-5-3 branch in the future.

-gustaf

Collapse
Posted by Matthew Coupe on
Thanks Gustaf, it worked a treat - not that it was ever in any doubt!

Next question... I'm trying to create a podcast for the class where I have mounted my wiki but when I add the podcast page as a portlet it takes over the entire screen and the contents isn't limited to the portlet.

Is there a way in which I can display the podcast listing within a portlet?

Collapse
Posted by Gustaf Neumann on
What do you mean by adding "podcast page as portlet"? the podcast itself is an xml file, rendering it passes xml mime-type, etc. That can't be embedded. The usual approach is to provide a link for the podcast. What we have done for the openacs-conference http://oacs-dotlrn-conf2007.wu-wien.ac.at/conf2007/ was to add a podcast icon with a link, as in:

[[image:podcast.jpg|Download Conference Presentationa as as Podcast|-href itpc://oacs-dotlrn-conf2007.wu-wien.ac.at/conf2007/podcast]]

For providing a link to a single podcast content file, use
[[file:ACSkonferenz_neumann_xowiki_cutVGA.mp4|Presentation Neumann]]

Collapse
Posted by Matthew Coupe on
Yeah I think that's the best approach - I was looking for a lazy way of listing all of the files in the podcast within an xowiki page but it's no big deal to link to them manually.

The syntax for the iTunes link was something I couldn't find so thanks for that too.

Collapse
Posted by Christian Fuchs on
Thanks for this link. Do you know how this would be possible, if the podcast is on an https:// webserver?

URL: https://learn.bildungsserver.com/podcast

If I link to itpc://learn.bildungsserver.com/podcast it opens itunes, but itunes looks for http://learn.bildungsserver.com/podcast not https://learn.bildungsserver.com/podcast.

Any ideas?

Collapse
Posted by Gustaf Neumann on
As far i know, a URL of the form itpc://somehost/somepage is always mapped to HTTP, and not to HTTPS. Podcasts are public, so the easiest approach is to accept podcast requests always via HTTP (allow HTTP for podcast urls).