different kinds of objects might have same-named methods (e.g. save) which might need different realizations (e.g. what has to be done for saving an abject). so, specialized subclasses can overload these methods.

concerning new changes on news-item. The version provided by malte continues to work (no one has to use the new news-item form page). The basic question is where to save the body of a message, in the description (plain text) or in the content of an item. Both options are open with the 5-3 version and the head version. i tend to believe that storing the content of items in the text is better, but in some aspects, the html has disadvantages (the 5-3 version converts to a semi-good text, it is harder to truncate the text to n characters due to wellformed-aspects of html).

In the worst case, one has to use another similar script to convert from old news-item to new news-item. The biggest problem with that is the ordering by publication date, which should go most likely into a separate field, since using modification dates on the CR are maintained by the triggers, which has the consequence, that each update script alters these dates... i will look more into the details in the near future.

That's a very good lesson about OO and XoTCL; thank you very much for that. In my weekend studies I can see a lot about what you said, and I'll be able to use this in my future developments.

About the news storage, I agree with you it should be stored in the text. I don't think the description field is intended to do that, and it looked like a strange solution to me. If we have an item in CR, its content should be the most important attribute, not the description.

I can see your changes in HEAD, but you said something that I don't know if I understood: do you have a xowiki-import script anywhere? In Malte's script above he puts the publish date in cr_revisions. In my little understanding about it this you've changed the select queries to retrieve the publish_date from cr_revisions. Am I right? If you did this, Malte's import script will work without any changes.

Afther your help in all these issues, I realized that I should upgrade my XoWIki and XoTCL versions. I was in version 0.60 of both and I'm upgrading now to the HEAD. i had a little trouble with XoTCL regarding the file xotcl-core/tcl/05-db-procs.tcl. In line 81 I had this:

if {[db_driverkey ""] eq "oracle"} {set name [string toupper $name]}

In my PostgreSQL version, this code was making the package check for the tables in upper case. So it tried to create the APM_PARAMETERS table, and I had to make an small change in order to make it work. My modified version was like this:

if {[db_driverkey ""] eq "oracle"} {
set name [string toupper $name]
} else {
set name [string tolower $name]
}


The error disapeared and I could upgrade XoTCL without any trouble. However, I'm still facing some trouble in XoWIki upgrade. The following error message appears in my log:


Error: content #
# A sample News object.
#
my initialize -parameter {
{-page_size:integer 10}
{-page_number:integer 1}
{-summary:boolean 0}
{-date ""}
{-tag ""}
{-ptag ""}
{-entries_of en:news-item}
}
(...)

set w [::xowiki::Weblog new -destroy_on_cleanup -package_id $package_id -page_size $page_size -page_number $page_numbe
r -summary $summary -date $date -category_id [ns_queryget category_id] -tag $tag -ptag $ptag -entry_label "News Article
s" -exclude_item_ids $exclude_item_ids -entry_renderer $entry_renderer -entry_flag __no_form_page_footer -entries_of $ent
ries_of ]
$w set __page $page
$w mixin add $renderer
return [$w render]
} lead to error: Transaction aborted: unknown argument '-childof' for method 'new': valid arguments {-dbn {}} -name:require
d -parent_id:required -item_id -locale {-creation_date now} -creation_user:required -context_id -creation_ip {-item_subtype c
ontent_item} {-content_type content_revision} -title -description {-mime_type text/plain} -nls_language -text -data -relation
_tag {-is_live f} {-storage_type lob} -package_id:required


Do you have any idea about how to fix it?

i was trying to figure out, why in your installation it checks for the table name "APM_PARAMETERS" while on my installations, it checks for "apm_parameters". Fixing one symptom does not help much, since you will run into similar problems later on.

Since xotcl-core uses the table name from acs_object_types for the parameter class, i am wondering, what the following query returns on your system:

select object_type, table_name from acs_object_types where object_type = 'apm_parameter'; 

I've never had any trouble using XoWiki in this version, and in my little understanding about the package, I couldn't see any change in the ACS-Core that would afect it.

The versions of xotcl-core in cvs head has a much wider support of the acs-type system (see e.g. http://www.openacs.org/forums/message-view?message_id=1165841)
and is much tighter integrated with it. the according xowiki versions use these features. There are changes in this regard in acs-core, see e.g. http://www.openacs.org/forums/message-view?message_id=1201818 for some consequences.

unlike most other packages, the xo* packages tried in the past to work as good a possible with about all kind of openacs installations. Therefore, there are already many
package dependencies included. Try the following for a better understanding of the dependencies:

fgrep -R "ad_acs_version" packages/xo* 

As said before, the head development is based on 5.3 and cvs head. Providing 5.2 support is probably not hard, but currently, i have no time to work on that.

btw, you did not state, what version of XOTcl you are using (grep for XOTcl in your error log).