Forum OpenACS Development: xowiki 0.46

Request notifications

Collapse
Posted by Gustaf Neumann on
Dear Community,

xowiki 0.46 is in CVS head. The newest features are:

  • support for the 'views' package
  • autonamed (anonymous) pages
  • extended package parameters (extra css, autoname, display_page_order, ...)
  • configuration and prototype page to use xowiki as an announcement package (similar to news)
  • Here is a short example how to create an "Announcements application":

    • create a new instance, e.g. named news
    • set the package parameters of this instance as follows
      • index_page := announcements
      • autoname := 1
      • display_page_order := 0
      • in oder to change title or layout, edit the index page (requires package admin).
      • Needless to say that this news application "inherits" all features from xowiki such as policies, production mode, syndication controls (like rss, digg, delicious), tagging, categories, local search, etc...

        Maybe, someone finds this useful

        best regards
        Gustaf Neumann

Collapse
2: xowiki 0.47 (response to 1)
Posted by Gustaf Neumann on
xowiki 0.47 is in CVS head. The biggest user-visible change is the support for delivering podcasts. What does this mean:

  • XoWiki has a new type ::xowiki::PodcastItem (subtype of ::xowiki::File) which manages the needed meta-data for podcasts.
  • XoWiki has a new prototype page "podcast" which outputs a podcast in the required format.

In order to provide a podcast, one has

  1. to create an audio or video stream in one of the supported formats (there is no xowiki support for this).
  2. Once the files are appropriately encoded, these can be uploaded to an xowiki instance (e.g. go to the admin page, press "add new podcast item") where the metadata is provided as well.
  3. A podcast page can be instantiated from the provided prototype page by calling e.g. .../name-of-your-xowiki-instance/podcast.
  4. The podcast specific meta-data (channel) can be provided by editing the podcast page (e.g. description, title).
  5. Finally point itunes to the podcast page

In order to upload mp4 files, one has to add the following entry to cr_mime_types:

insert into cr_mime_types (label,mime_type,file_extension) values ('Video MP4', 'video/mp4', 'mp4');

This tuple should go into the future releases of openacs.

For an example of the podcast, tune your itunes to:
http://alice.wu-wien.ac.at:8000/xowiki/podcast

best regards
-gustaf neumann

Collapse
3: Re: xowiki 0.47 (response to 2)
Posted by Malte Sussdorff on
I looked at your podcasts, they are interesting, you should make more resources available that deal with OpenACS. I don't mind them being in German :-).

Which software did you use for the recording ?

Collapse
4: Re: xowiki 0.47 (response to 3)
Posted by Eduardo Santos on
Hi everybody,

I don't know if it's related to the new version of xowiki, but I found some bug on xinha. It seems like everytime we try to put a link in the editor, such as

http://servertest/dotlrn/clubs/club/file-storage/view/File.pdf

the xinha editor kills the outside piece of the link. So, when we use it to send an email, the messgae to be sent will have the link like this:

/file-storage/view/File.pdf

Let me know if I put this in the wrong place so I can redirect the post.

Collapse
5: Re: xowiki 0.47 (response to 4)
Posted by Gustaf Neumann on
Eduardo,

your question is primarily a xinha issue, not an xowiki issue. To be more precide, mozilla mangles the URLs, but xinha has some options to deal with such issues.

The actual version of Xinha (in cvs head) has the following config parameter in this regards:


// specify a base href for relative links
this.baseHref = null;

// when the editor is in different directory depth as the edited page relative image sources
// will break the display of your images
// this fixes an issue where Mozilla converts the urls of images and links that are on the same server
// to relative ones (../) when dragging them around in the editor (Ticket #448)
this.expandRelativeUrl = true;

// we can strip the base href out of relative links to leave them relative, reason for this
// especially if you don't specify a baseHref is that mozilla at least (& IE ?) will prefix
// the baseHref to any relative links to make them absolute, which isn't what you want most the time.
this.stripBaseHref = true;


// see if the text just typed looks like a URL, or email address
// and link it appropriatly
this.convertUrlsToLinks = true;

The version of Xinha in oacs-5-3 or earlier does not have expandRelativeUrl and convertUrlsToLinks.

i would recommend to try the xinha version (and richtext-procs,blank-master) from CVS head, setting

xinha_config.convertUrlsToLinks = 0;

in blank-master before makeEditors() is called.

On your XoWiki page, write


[[http://servertest/dotlrn/clubs/club/file-storage/view/File.pdf|My pretty PDF File]]

instead (well the forum makes from the url a link, just write the url). This should resolve such issues.

Collapse
6: Re: xowiki 0.47 (response to 5)
Posted by Eduardo Santos on
Thanks Gustaf, I knew it was not a xowiki issue, but I thought you could help me. Next time I'll look for it in the xinha forums.

Anyway, your suggestion worked just fine. Thank you for that. Did you commit this option to the blank master in HEAD? Just in case somebody else has the same trouble.

Collapse
9: Re: xowiki 0.47 (response to 2)
Posted by Nima Mazloumi on
I have troubles with xowiki. Any idea why I get this error:

wrong # args: should be "ns_cache names cache"
while executing
"ns_cache names xowiki_cache $key"
(procedure "delete" line 21)
::2748 ::xowiki::Package->delete
invoked from within
"$object $method"
(procedure "call" line 7)
::2748 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 8)
::2748 ::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 "/www/oacs-5-3/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..."

Collapse
10: Re: xowiki 0.47 (response to 9)
Posted by Gustaf Neumann on
try:

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

get the file, recompile and install ns_cache

Collapse
12: Re: xowiki 0.47 (response to 2)
Posted by Nima Mazloumi on
Thank you.

Another question. In a page template I have placed:

{{adp portlets/categories {name {References} tree_name *ref*}}}

But I get this when viewing the page:

Error in '{{adp portlets/categories {name {References} tree_name *ref*}}' in en:bookRef (unmatched open brace in list)
Syntax: adp <name of adp-file> {<argument list>}
Invalid argument list: 'portlets/categories {name {References} tree_name *ref*'; must be attribute value pairs (even number of elements)
}ยด
Any idea?

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

Collapse
23: Re: xowiki 0.47 (response to 2)
Posted by Byron Linares on
Hi. Gustaf

I have troubles with xowiki 0.47
I trying to set a new policy that Works for me
I want that only site Wide admin. Cant create a xowiki::Object and ::xowiki::PageTemplate
And only site Wide admin. Cant do programmatical operations

For example with ::xowiki::Object in try this code

In Class Package -array set require_permission {

edit-new {{{has_class ::xowiki::Object} id swa} {id create}}

but get this when I try to create a xowiki::Object

::47934064: unable to dispatch method 'name'
while executing
"$object name"
("default" arm line 19)
invoked from within
"switch $permission {
none {set allowed 1; break}
login {auth::require_login; set allowed 1; break}
swa {
..."
(procedure "check_permissions" line 12)
::xowiki::policyb ::xowiki::Policy->check_permissions
invoked from within
"$policy check_permissions $object $method"
(procedure "call" line 5)
::47934064 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 8)
::47934064 ::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 "/Users/byronharoldolinaresroman/www/ges2wiki/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..."

if y try this code
In Class Package -array set require_permission {
edit-new {{{has_class ::xowiki::Object} swa} {id create}}

I get this error when I try to create any kind of page
can't read "has_class ::xowiki::Object": no such variable
::47934064 ::xotcl::Object->set
invoked from within
"$object set $attribute"
("default" arm line 13)
invoked from within
"switch $permission {
none {set allowed 1; break}
login {auth::require_login; set allowed 1; break}
swa {
..."
(procedure "check_permissions" line 12)
::xowiki::policyb ::xowiki::Policy->check_permissions
invoked from within
"$policy check_permissions $object $method"
(procedure "call" line 5)
::47934064 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 8)
::47934064 ::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 "/Users/byronharoldolinaresroman/www/ges2wiki/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..."

Thanks for you help

Collapse
24: Re: xowiki 0.47 (response to 23)
Posted by Gustaf Neumann on
In order to allow only side wide administrators to edit ::xowiki::Object, you can simply use ::xowiki::policy2 instead of ::xowiki::policy1. The policy is a package parameter (called security_policy), so there is no need to edit the source files for such a feature.

For more details, see http://alice.wu-wien.ac.at:8000/xowiki-doc/#security-management

Collapse
25: Re: xowiki 0.47 (response to 24)
Posted by Byron Linares on
I am writing a new policy for my instance of xowiki
I want that only site Wide admin Can Create a ::xowiki::PageTemplate
And xowiki::Object but policy2 only cover the edit part,
In my policy I am try set permission for create this object like this

Policy policyb -contains {

Class Package -array set require_permission {
reindex swa
rss swa
google-sitemap none
google-sitemapindex none
delete {{id admin}}
edit-new {{{has_class ::xowiki::Object} swa} {id create}}
}
.
.
.
.

when I change the security_policy parameter and set my new policy I get and error that i describe in a previous post

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

my question is how can I restrict the creation or edit-new for only site Wide admin for this tow (a ::xowiki::PageTemplate And xowiki::Object)

Other question is :
There is a way for page ordering in wiki 0.47
I have set the parameter display_page_order and fill the section field in creations forms but I can figured a way to order those pages
in the xowiki side menu

thack for you help.

Byron

Collapse
26: Re: xowiki 0.47 (response to 25)
Posted by Gustaf Neumann on
The relevant line in the policy should read

edit-new {{{has_class ::xowiki::Object} swa} {{has_class ::xowiki::PageTemplate} swa} {id create}}

This works with the current versions of xowiki. If you get still an error with this definition, upgrade to a slightly newer version (0.48, version of March 10) where i refactored much of the policy stuff (update both, xowiki and xotcl-core to the version of the same day).

Concerning your question about page ordering: i assume, you have in the edit form the entry field and you provided some values for this. Simply type in the URL .../xowiki/book and you get the pages displayed (book is a prototype page, which is created on demand from the filesystem and is inserted into the content repository where you can edit it etc for every instance).

I have started to make an FAQ about xowiki: http://alice.wu-wien.ac.at:8000/xowiki-faq/

maybe this helps to answer some of the questions.

Collapse
27: Re: xowiki 0.47 (response to 26)
Posted by Byron Linares on
thacks gustaf,
the upgrade worcks for the policy part.
Collapse
28: Re: xowiki 0.47 (response to 2)
Posted by Matthew Coupe on
Creating a Podcast Item has a strange behaviour in Internet Explorer.

When I try to upload a .mov file without entering anything in the name field the file is uploaded with the filename being the entire path to the file. Then when I try to view this file it says that it cannot be found on the server.

For instance C:/podcasts/mymovie.mov

when uploaded becomes file:C:\podcasts\mymovie.mov

This seems to be specific to Internet Explorer and only happens when you don't give the file a name. If you give the file a name which isn't a .mov extension it doesn't seem to work either.

Any ideas?
Thanks for the help.

Collapse
29: Re: xowiki 0.47 (response to 28)
Posted by Gustaf Neumann on
what happens, if you specify mymovie.mov in the name field?
Collapse
30: Re: xowiki 0.47 (response to 29)
Posted by Matthew Coupe on
The movie works perfectly.
Collapse
31: Re: xowiki 0.47 (response to 30)
Posted by Gustaf Neumann on
The following fix should help. I could not test on IE so far, please check and report if it works or not.

http://cvs.openacs.org/cvs/openacs-4/packages/xowiki/tcl/xowiki-procs.tcl?r1=1.162.2.3&r2=1.162.2.4

best regards
-gustaf neumann

Collapse
7: Re: xowiki 0.48 + locales (response to 1)
Posted by Malte Sussdorff on
I figured out after some digging, that the "default" locale switch is not the default anymore for categories in XoWIKI and if you want the behavior of "search my locale and if not found search system locale", you have to explicitly pass it with "-locale default+system"

If you on the other hand only want German, you could pass "-locale de_DE". Or only German plus system "-locale de_DE+system". You get the picture...

I remember reading something about a package level default locale (so you could have different default locales depending on the package instance of XoWIKI). In the code it says to set the locale according to the package, but I could not find out where to set this in the administration interface.

Collapse
8: Re: xowiki 0.48 (response to 1)
Posted by Malte Sussdorff on
Two more things which I could not change myself and maybe Gustaf can shed some light on:

a) When I create a new page, the locale is set to the system_locale. Is this on purpose? Can't I create a new page in my own locale first?

b) When clicking on the link "Create this page in your own language", the name is preset. Sadly this is not true for the locale (still system locale, which is annoying / causes user errors) and not for the categories (they are empty though they should be the same as in the default locale).

Collapse
11: Re: xowiki 0.46 (response to 1)
Posted by Dave Bauer on
You need to use the CVS version of ns_cahe with xowiki.
Collapse
14: Re: xowiki 0.46 (response to 1)
Posted by Nima Mazloumi on
perfect. thank you.

I've been playing around with page templates. any objection if i extend it with a way to provide a field type and wether the field is required or optional?

what about this:

default:

@field@ --> required, type textara

new:

@field:type:optional@ --> optional field of a given type. For example:

@start_date@:date:optional@ will result in a date selection widget

Collapse
15: Re: xowiki 0.46 (response to 14)
Posted by Gustaf Neumann on
Just specifying type is not sufficient, extending the at-sign-syntax is not scalable.

look at the widget_specs in http://alice.wu-wien.ac.at:8000/xowiki-doc/

one can specify per field and page template the widgets (most prominently via editing the folder object), one can use multiple xinhas, or selection boxes, etc... the conference site was made with a page template.