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

Request notifications

Hi everybody,

the two apm files below provide linkage between xowiki and dotlrn. these two packages allow to use xowiki pages in a similar way as the static-portlet in dotlrn portals.

Small howto:

Collapse
Posted by Malte Sussdorff on
This sounds good and will be helpful for .LRN to get rid of static portlets. Finally :).

Here are some comments though:

a) Providing the URL via APM is great, if the install from URL process would work :-). At least on my Ubuntu it failed miserably, so I had to download the APM in the /packages directory and untar it manually

b) When I add the page (selecting on from the drop down box), this is what happens:

Error:

No page 'admin/portal-element-add' available.

From the URL:

/dotlrn/clubs/technics/xowiki/admin/portal-element-add

I found out why: You added the page to xowiki, but did not increase the version and the dependency, so I had to first update XoWIKI in CVS :).

Now this works, but I wonder if there is a parameter to NOT display the editing links (or search aso.) in the portlet itself. Not sure if you want to have them in a portlet. And if you do, it would make more sense to have an edit button in the portlets header.

Last but not least, will you commit it to CVS ?

Collapse
Posted by Gustaf Neumann on
... get rid of static portlets
that was not the intention
... install from URL process would work :-). At least on my Ubuntu it failed miserably
What is "install from url"? most likely, this requires manifest.xml etc. yes, it has to be installed "manually", by untaring the apm file in the package directory for now.
You added the page to xowiki, but did not increase the version and the dependency ... so I had to first update XoWIKI in ...
i did increas the version number and provided the dependency. the new version (since 9h) is xowiki 0.44, the dependency for this version is in xowiki-portlet.info.
... I wonder if there is a parameter to NOT display the editing links (or search aso.)
Well the idea of the wiki is to let people edit the contents (if they have the permissions). Also index etc. makes sense IMHO to get access to the full wiki.

Concerning parameters: for portal elements, there are the portal_element_parameters (which seem to have no user-friendly interface). in general, with portal_element_parameters it is possible with little work to specify per portal element different the xowiki templates.

for now, change e.g. in xowiki-portlet/www/xowiki-portlet.adp "view-links" to "view-plain" to get rid of the links.... or roll your own template.

Last but not least, will you commit it to CVS ?
if there is enough interest, why not.

Collapse
Posted by Jose Pablo Escobedo Del Cid on
That's great news! thanks Gustaf. I had already implemented a quick "integration" of xowiki and .LRN with the static portlet with a link to a xowiki instance solution. But this is much better :)

Just one comment/bug: the content of the portlet doesn't fit in correctly.

Regards,

Jose Pablo

Collapse
Posted by Gustaf Neumann on
Just one comment/bug: the content of the portlet doesn't fit in correctly.
are you talking about the default index page?
This seems to be a css problem which does not like to see
a "portlet-title" or "portal" css class within another "portal".

if this is the problem, edit the index page and add "-decoration plain" to the includelets (between the double curly braces, without the quotes) to see the effect.

Try to write a text page, it should fit nicely.

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 Eduardo Santos on
Just another thing. after upgrade xowiki from version 0.39 to head, I got the following errors in my log:

Error: Error sourcing /var/www/dev-lrn/packages/xowiki/tcl/xowiki-www-procs.tcl:
invalid command name "File"
while executing
"File instproc download {} {
my instvar text mime_type package_id item_id revision_id
$package_id set mime_type $mime_type
set use_bg_deliv..."
(in namespace eval "::xowiki" script line 278)
invoked from within
"namespace eval ::xowiki {

Page instproc view {} {
# view is used only for the toplevel call, when the xowiki page is viewed
# this is not..."
(file "/var/www/dev-lrn/packages/xowiki/tcl/xowiki-www-procs.tcl" line 10)
invoked from within
"source $__file "

And the other one:

Error: Error sourcing /var/www/dev-lrn/packages/xowiki/tcl/xowiki-procs.tcl:
during '::xotcl::__#3 contains'
::xotcl::__#3 ::xotcl::Object->configure
::xo::OrderedComposite ::xotcl::Class->create
::xo::OrderedComposite ::xotcl::Class->new
invoked from within
"::xo::OrderedComposite new -contains [my cr_attributes]"
(procedure "init" line 8)
::xowiki::Page ::Generic::CrClass->init
::Generic::CrClass ::xotcl::Class->create
invoked from within
"::Generic::CrClass create Page -superclass ::Generic::CrItem -pretty_name "XoWiki Page" -pretty_plural "XoWiki Pages" -table_name "xowiki_page" -id_..."
(in namespace eval "::xowiki" script line 6)
invoked from within
"namespace eval ::xowiki {

#
# create classes for different kind of pages
#
::Generic::CrClass create Page -superclass ::Generic::CrItem \
..."
(file "/var/www/dev-lrn/packages/xowiki/tcl/xowiki-procs.tcl" line 9)
invoked from within
"source $__file "

Collapse
Posted by Eduardo Santos on
Forget about the errors above. I found your post:

http://openacs.org/forums/message-view?message_id=546200

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 Gustaf Neumann on
both packages are checked into cvs head
Collapse
Posted by Carl Robert Blesius on
Excellent, thanks Gustaf. I look forward to trying it out on our .LRN server.
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.

http://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 Nima Mazloumi on
I have installed latest code from oacs-5-3 and dotlrn-xowiki, xowiki-portlet from head. after adding the xowiki applet to a community i get the following error in the admin portlet:

Error in include template "/srv/www/openacs-4/packages/xowiki-portlet/www/xowiki-admin-portlet": unknown argument '-order_clause' for method 'instance_select_query': valid arguments {-select_attributes {}} {-orderby {}} {-where_clause {}} {-from_clause {}} {-with_subtypes:boolean true} -publish_status {-count:boolean false} -folder_id {-page_size 20} {-page_number {}}

Is my xotcl (1.5.3) too old?

Collapse
Posted by Gustaf Neumann on
no, your xotcl-core was to new. fixed in cvs head.
Collapse
Posted by Nima Mazloumi on
I updated latest code from head for xotcl-core and xowiki. still there is the error in the admin portlet. anything I forgot?
Collapse
Posted by Nima Mazloumi on
I found a little bug in xowiki-portlet. I created a wiki page and included an swf file. in xowiki directly the flash animation is shown but when I add the page as a portlet to dotlrn only the text is shown but not the flash film.

any idea?

Collapse
Posted by Gustaf Neumann on
passing header-properties from the xowiki include to the dotlrn master templates was not implemented.... and is quite tricky. i never figured out, what a clean way is to pass properties form includes to the master, esp. when the includes are deeply nested.

The quick solution is as follows:

Collapse
Posted by Dave Bauer on
This is the generic implementation of what gustaf is referring to:

http://openacs.org/xowiki/templatehead

This should be in CVS on HEAD soon.

Collapse
Posted by Nima Mazloumi on
Not sure if we are talking about the same thing. What I am saying is that an xowiki page rendered inside a portlet does not render included files like a flash movie. The same page direclty rendered in xowiki displays the movie.
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 Christian Fuchs on
Is it only possible to "link" pages manuelly (which is great) into the portlet or would it be also possible that within the portlet the last n pages with description are automatically displayed. (Maybe with selection of category. So one could define also a category which is then displayed within the portlet.
We need this feature for a "to-do list" which should automatically display all entrances.
Nice thing would be that one could change the layout within the portlet on an xowiki:object page (like with en:weblog-portlet, ie. en:dotlrn-portlet which is then rendered into the actual portlet on the dotlrn-portal.)

Thanks

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).
Collapse
Posted by Gustaf Neumann on
hmm, not sure, i understood you correctly. If you want a dotlrn portlet, which lists e.g. the most recent open items/task/... with a short description, i would recommend the following:

a) create a new category tree "state of work" with e.g. categories "open", "under work", "done" and map it to the xowiki of the community.

b) create an xowiki page for e.g. the open items (en:open) with a content like
----
{{weblog-portlet -category_id 4305 -summary 1 -decoration plain}}
----
where the category_id is the one for the open items (find the category_id e.g. via "en:weblog", by clicking on the categories)

c) add the xowiki page "en:open" as portlet from the admin-page of the community

If you create some pages with an description, categorized with "open", you will get the listing with the description in the page en:open (since "-summary 1" is used above).

In case, you want to change the layout of the summary, edit en:weblog-portlet (or rename it) and change the WeblogRenderer (responsible for rendering the full listing) and/or the EntryRenderer (responsible for rendering a single entry). Most likely it is sufficient to remove some of the markup. If you rename e.g. en:weblog-portlet to en:listing, don't forget to change the name as well in (b) above.

Does this help?

-gustaf neumann
PS: i have just updated the weblog-portlet to accept the category_id from the includelet call. If you have a fairly recent installation, you should be able to make the following change to packages/xowiki/www/prototypes/weblog-portlet.page
http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/www/prototypes/weblog-portlet.page?r1=1.12&r2=1.13

Collapse
Posted by Christian Fuchs on
Perfect, thank you very much :-)
Collapse
Posted by Eduardo Santos on
Hi everybody,

I have a little doubt about the way xowiki portlets are inserted in community pages. My Portal has a growing need for internationalization, in such a way that even the community content must be in many languages. The community description, static info, everything must be internationalized.

The best way to do that was to use Xowiki Portlets to serve multi-language content, the same way as it's done in Xowiki when use_conncetion_locale parameter is set to 1. However, I found a problem when trying to do that: the portlets are created based on the full page name, wich includes the locale already (ex.: en:index). In that way, every page translation is like a different portlet.

I was trying to discover how to solve this, but I've stucked in my poor Xowiki skills. I've seen that the creation request is sent to the xowiki/www/admin/portal-element-add, wich gets the page_id using the page_name by the resolve_request method. It would be also necessary to change te portlet render page, wich seems to me the /xowiki/lib/view file.

So, can you guys point me a direction to solve this issue?

Collapse
Posted by Gustaf Neumann on
Dear Eduardo,

you are right, that the behaviour should be improved. Actually, one would need an additional option at portlet registration time to tell, whether the added page should be in a specified language (e.g. en), or that the language should be determined dynamically. There are as well some more shortcomings in the current dotlrn portal system (see below).

How to get connection locale specific text pages:

a) set in the package parameter of the community wiki use_conncetion_locale to 1 (you have that already)

b) In portal-element-add.tcl make the change below, which simply strips the language prefix from the page name used for resolving (the include or "resolve_request" do already the "right thing")

After this is done, you will see the pages.

However, the dotlrn portlets are defined in a way such that the title of the dortlrn portlet (pretty_name) is copied typically during registration time. Therefore, the title will be - without further work - always in one language, which is not nice, but might be sufficient for some use cases.

The easiest way out is to use in the xowiki page as title not a text page-title, but instead a language key (e.g. #xowiki.title_of_page1#). The approach with the message keys will work, but some new issues will pop up: (a) this is not nice from the xowiki point of view, (b) one would need a package for the community to provide a base for the message keys.

There is - up to a certain point - support in new-portal for computed titles, since the title of a portal element can be determined via service contract. However, the parameters are cached, and "GetPrettyName" does not get sufficient context to be useful.

I am not sure, whether it is worth to invest resources into this, since the xoportal approach presented in Guatemala does not suffer from these shortcomings.

For the time being, if you can live with single language title, or the message-key approach, the small change below should help you.

best regards
-gustaf neumann

--- admin/portal-element-add.tcl	27 Feb 2008 09:12:07 -0000	1.8
+++ admin/portal-element-add.tcl 31 Mar 2008 08:48:54 -0000
@@ -56,7 +56,8 @@
-package_key "xowiki-portlet"]
]
portal::set_element_param $element_id package_id $package_id
- portal::set_element_param $element_id page_name [$page_id name]
+ regexp {^..:(.*)$} $page_name _ page_name
+ portal::set_element_param $element_id page_name $page_name
}
ad_returnredirect $referer
}

Collapse
Posted by Eduardo Santos on
Hi Gustaf,

Thank you very much for your help again. I was thinking about to do almost the same thing you told but your approach is the best, as usual.

I've seen your presentation video about xoportal and I'm very excited about it. Let me know if I can help somehow.

Thank you for the help again.

Collapse
Posted by Eduardo Santos on
Hi Gustaf,

I've made some tests with your patch and it seems to be working fine. I only had to make some changes in the Portlet Admin Page to make sure you insert only one page, it doesn't matter the locale you are using. Otherwise you could have duplicate content. Check out this patch:

Index: xowiki-portlet/www/xowiki-admin-portlet.tcl
===================================================================
--- xowiki-portlet/www/xowiki-admin-portlet.tcl (revisão 364)
+++ xowiki-portlet/www/xowiki-admin-portlet.tcl (cópia de trabalho)
@@ -55,9 +55,16 @@
      -where_clause "P.page_id = cr.revision_id" \
      -orderby "ci.name" \
      ] {
+      # Clean the locale from the page name
+      regexp {^..:(.*)$} $name _ name2
        if {[regexp {^::[0-9]} $name]} continue
        if {[info exists used_page_id($name)]} continue
-      append options "<option value=\"$name\">$name</option>"
+      # Check if the page without locale is alredy inserted
+      if {[info exists used_page_id($name2)]} continue
+      # Make sure we insert only one locale for the same page
+      if {![string match "*$name2*" $options]} {
+          append options "<option value=\"$name\">$name</option>\n"
+      }
      }

  if {$options ne ""} {
}]