Forum OpenACS Development: Re: Upgrade to xowiki 0.52

Collapse
7: Re: Upgrade to xowiki 0.52 (response to 5)
Posted by Jose Pablo Escobedo Del Cid on
Hi,

I'm having the same problem after upgrading to xowiki0.52.

I have two customized adp pages placed under the xowiki/www/portlets directory. They worked fine before the upgrade.

One of them receives two parameters and the other one doesn't receive any. The one that doesn't receive parameters is working fine (using the first case syntaxis below), whereas with the other one I get this error:

1. line in xowiki: {{adp /packages/xowiki/portlets/wwwgradient-public-blog {package_id 2370}}}

error message:
Error in '{{adp /packages/xowiki/portlets/wwwgradient-public-blog {package_id 2370}}' in en:main_page (unmatched open brace in list)
Syntax: adp < name of adp-file> {< argument list>}
Invalid argument list: '/packages/xowiki/portlets/wwwgradient-public-blog {package_id 2370'; must be attribute value pairs (even number of elements)
}

2. line in xowiki: {{adp /packages/xowiki/portlets/wwwgradient-public-blog -package_id 2370}}

error message:
Error in '{{adp /packages/xowiki/portlets/www/gradient-public-blog -package_id 2370}}'
Syntax: adp < name of adp-file> {< argument list>}
Invalid argument list: '-package_id'; must be attribute value pairs (even number of elements)

3. line in xowiki: {{gradient-public-blog -package_id 2370}}

error message:
Error: includelet 'gradient-public-blog' unknown

Finally, copy&paste the syntaxis of the doc page http://alice.wu-wien.ac.at:8000/xowiki-doc/#adp-includes) also gives an error:

1. xowiki line: {{adp /packages/calendar/www/mini-calendar {view day base_url /dotlrn/calendar/}}}

error message:
Error in '{{adp /packages/calendar/www/mini-calendar {view day base_url /dotlrn/calendar/}}' in en:main_page (unmatched open brace in list)
Syntax: adp < name of adp-file> {< argument list>}
Invalid argument list: '/packages/calendar/www/mini-calendar {view day base_url /dotlrn/calendar/'; must be attribute value pairs (even number of elements)
}

Thanks in advance,

jopez

Collapse
8: Re: Upgrade to xowiki 0.52 (response to 7)
Posted by Matthew Coupe on
Hey Jose,

I'm getting the same error messages when using the oacs-view for displaying the category tree.

Seems something has stopped the {{adp etc. functions from working?

Cheers,
Matthew

Collapse
9: Re: Upgrade to xowiki 0.52 (response to 8)
Posted by Matthew Coupe on
Uh-oh!

the file upload function seems to have gone AWOL too.

can't read "package_id": no such variable
while executing
"::$package_id normalize_name $stripped_name"
(procedure "complete_name" line 14)
::xotcl::__#02 ::xowiki::File->complete_name
invoked from within
"$data complete_name $name [$data set upload_file]"
(procedure "::xowiki::validate_name" line 8)
invoked from within
"::xowiki::validate_name"
("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 58)
::xotcl::__#02 ::xowiki::Page->edit
invoked from within
"$page edit -new true -autoname $autoname"
(procedure "edit-new" line 7)
::2162207 ::xowiki::Package->edit-new
invoked from within
"$object $method"
(procedure "call" line 7)
::2162207 ::xowiki::Package->call
invoked from within
"my call $page $method"
(procedure "invoke" line 8)
::2162207 ::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/dotlrndev/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
Posted by Gustaf Neumann on
the file upload issue is fixed in cvs head.
Collapse
Posted by Gustaf Neumann on
jopez.

if you look at the braces of your example 1, you see problem: The parenthesis are not parsed correctly. if you change the line to

{{adp /packages/xowiki/portlets/wwwgradient-public-blog {package_id 2370} }}

the matching of double curly parenthesis will work again. When the adp tag is used within curly braces, xowiki does not do further processing of the arguments, so your attempt #2 will now work, since this is not a valid syntax for adp includes. Omitting adp in your example 3 does not help either, since you have obviously only an adp include file. The includelet syntax without "adp "is allowed only for including other pages and for library based includelets, which are similar to widgets (see {{available-includelets}}).

The problem occurred due to double-parenthesis matching with regular expressions, which has its limits. i have changed for now the regular expression for the matching of the closing parenthesis into double-parenthesis followed by white space, so, actually the first example should work again in the updated version in cvs.

Finally, i would not recommend for casual xowiki users to use currently the version from cvs head. i am working on major extensions and restructurings, so it is not so unlikely that whatever version you get might have some issues. A more safe policy is to take versions that i announced in the forums (use for checkout the date of the release notes) or to wait for the next released version with release notes.

Collapse
Posted by Jose Pablo Escobedo Del Cid on
Thank you for the fix and for the advice, it is working fine now.
Collapse
Posted by Matthew Coupe on
Hi Gustaf,

I'm having a bit fo a nightmare with this today!

I followed your advice and installed version 0.47, now when I try to go to the admin pages of an xowiki instance I am getting the following: (Same thing with 0.48 too. I tried a version from head again and it had problems with oacs-view with the category tree)

Thanks so much for your help, I'm determined to get a working version as this package has so much to offer!

invalid command name "::xowiki::Form"
while executing
"$object_type instance_select_query -folder_id [::$package_id set folder_id] -count 1 -with_subtypes false"
invoked from within
"db_list count [$object_type instance_select_query -folder_id [::$package_id set folder_id] -count 1 -with_subtypes false]"
invoked from within
"t1 add -object_type $object_type -instances [db_list count [$object_type instance_select_query -folder_id [::$package_id set folder_id] -count 1 -..."
("uplevel" body line 4)
invoked from within
"uplevel 1 $code_block "
("1" arm line 1)
invoked from within
"switch $errno {
0 {
# TCL_OK
}
1 {
# TCL_ERROR
..."
("while" body line 20)
invoked from within
"while { [db_getrow $db $selection] } {
incr counter
if { [info exists array_val] } {
unset array_val
..."
("uplevel" body line 5)
invoked from within
"uplevel 1 $code_block "
invoked from within
"db_with_handle -dbn $dbn db {
set selection [db_exec select $db $full_statement_name $sql]

set counter 0
while { [db_getrow $..."
(procedure "db_foreach" line 36)
invoked from within
"db_foreach type_select "select object_type from acs_object_types where
tree_sortkey between :object_type_key and tree_right(:object_type_key..."
("uplevel" body line 35)
invoked from within
"uplevel {
::xowiki::Package initialize -ad_doc {

This is the admin page for the package. It displays all of the types
of wiki pages provides li..."
(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..."

Collapse
Posted by Gustaf Neumann on
Matthew, this does not look good. you have parts of the newest and somewhat experimental stuff in the databse, and there are no "downgrade" scripts from new versions into old version. ::xowiki::Form and ::xowiki::FormInstance are extensions of ::xowiki::PageTemplate and ::xowiki::PageInstance, which might be merged before the release. Both classes are very new, you will get the same problems with every other older version now as well.

The following to sql calls should most probably work to downgrade

select acs_object_type__drop_type('::xowiki::Form','t') from dual;
select acs_object_type__drop_type('::xowiki::FormInstance','t') from dual;

If not, i would say, stay for now with the head version.

-gustaf

Collapse
Posted by Matthew Coupe on
No problem Gustaf, working on a dev machine anyway so I can start afresh on Monday if the scripts don't work.

We are running 0.37 in production so I'll try going straight to version 0.47 from there as that seems like a reasonable release - I feel like I'm missing out if I go too low on the version! We're not due to release the stuff we're working on for a couple of months so maybe by then there will be a further stable upgrade.

Thanks for all of the help.