Forum OpenACS Development: Re: Lars Blogger multilanguage support

Posted by Gustaf Neumann on
while it is true, that i made many improvements on this front, these are only in cvs-head and not on older versions.

concerning "new": every xotcl object or class has a set of methods inherited from the most general classes. The method "new" is in xotcl a method to create a fresh, "unnamed" object in memory. The predefined xotcl methods are described on

Concerning the missing body of the blog entries. The ::xowiki::Form "en:news-item" defines the entry form and the display of a news item. In the version it is shipped, it uses the "description" and not the "text" for keeping the entry. Therefore, Malte's script should be changed to use

-description $content \
-text "" \
to import the news item correctly. Alternatively, one could use in the "en:news-item" definition instead of "@_description@" the name "@_text@" to display the context of the text field instead of the description field.

This is similar to what i use currently in the head-version. It has many small improvements, like e.g. rich-text syndication, many small usability improvements, better styling through CSS, etc.

Posted by Eduardo Santos on
Hi Gustaf,

Now that I'm sutdying a little bit more of XoTCL I can see what you say about the methods. I didn't know about XoTCL predefined methods, and I can see now the advantages uf using it.

About the blog entries, I've checked the HEAD version and I could see the improvements you've made in the news-item prototype page. I have only a simple question regarding this: if I use Malte's import scripts am I going to be able to use all of them? Or I'll have to use another script so all the new stuff can work?

Posted by Gustaf Neumann on
one of the basic oo concepts is the idea, that one performs methods on objects. The methods for all kind of objects are defined by the most-general classes, which are provided by the XOTcl implementation.

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.

Posted by Gustaf Neumann on
The updated version in cvs head supports now ordering by publish date, and allows entries (e.g. news-items) to specify and modify the publish date explicitly. also, xowiki-import preserves now the publish date.

The news-item prototype page contains now the publish date.

Posted by Eduardo Santos on
Hi Gustaf,

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.

Posted by Gustaf Neumann on
on xowiki/admin, there is an "export" and "import" button for selective backup and for transfering content between different xowiki packages or different oacs installations. malte's script does not use this.

it is also correct that the publish_date is the one from cr_revisions. without further action on the xowiki side, the publish_date was/is altered each time set_live_revision is issued, which happens per default in the save and save_new methods. With the changes, it is now possible to preserve the given date.

Since the "standard" publish_date is used, there are no changes required in this regards in malte's script.

concerning content vs. description: this is a matter of the point of view: when the full story is stored on a different server, one has just a small description (like an abstract) of the full story in an xowiki page (and in RSS), plus a link to the full text. Furthermore, in many syndication applications, the description is required to be plain text, so there are as well some arguments for this variant.

With xowiki it is quite easy to go both ways for representing news-items, even in one instance by e.g. using two different ::xowiki::Forms. As mentioned before, the default variant is the one using the text content.

17: Upgrade problem (response to 16)
Posted by Eduardo Santos on
Hi Gustaf,

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?

18: Re: Upgrade problem (response to 17)
Posted by Gustaf Neumann on
First of all, the head version is a moving target, you should not use it in a production environment. the code contains many experimental features, which might disappear in a released version. use it with caution. Furthermore, i test the head version most times with openacs-head, and sometimes with oacs-5-3.

there is something strange in your setup. there should be no need to create the apm_parameters table, since you should have it already. what openacs version are you using? what version of xotcl do you use (did you run the aa-test on xotcl-core to check the requirements)?

19: Re: Upgrade problem (response to 18)
Posted by Gustaf Neumann on
one more question: what version of postgres are you using?
20: Re: Upgrade problem (response to 18)
Posted by Eduardo Santos on
Hi Gustaf,

I understand what you said about the HEAD version, and I'm trying to be cautious. Maybe that's why I'm facing these troubles.

About the apm_parameters table, it should not be necessary to create it, indeed. The problem is that the script was checking for the APM_PARAMETERS table, wich is upper case, and it was not able to find it. I have changed the code to make it check for the lower case apm_parameters table, and XoTCL could be upgraded without any other troubles.

This is my version list:
ACS-Core 5.2.3
dotLRN 2.2.1
PostgreSQL 8.1.3
XoTCL-Core 0.56.3
XoWiki 0.60

I know most of the XoWiki development is based on oacs-5-3, but as we didn't have an stable version, I've chosen to stay in oacs-5-2. I'll be looking at the upgrade scripts the next weeks. 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.

Studying a little bit more the upgrade error, I could see it breaks at the upgrade callback, when it tries to set the version 0.77. The error shows up when the XoWiki tries to import the news prototype page (line 363 in file xowiki/tcl/xowiki-callback-procs.tcl).

I appreciate your time spent with this matter, Gustaf. I know you are a very busy person, and thank you very much for your help.

21: Re: Upgrade problem (response to 20)
Posted by Gustaf Neumann on

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.
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. 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).

22: Re: Upgrade problem (response to 21)
Posted by Eduardo Santos on
Hi Gustaf,

I'm starting to think you are right about the compatibility problem. Maybe the new version of XoTCL can not be used in ACS-Core 5.2.3. The query you've mentioned returned the APM_PARAMETERS indeed. It has something to do with this diff:

It seems like the data model changed a lot between the oacs-5-2 and the oacs-5-3, wich makes me think a version upgrade will be needed in order to make XoTCL and XoWiki work appropriately. I could work in some changes to provide oacs-5-2 compatibility, but I don't know if it's worth. My upgrade fear is allways related to the compatibility of my systems, assuming all the changes I've done myself, but I guess there's no other way.

At least I can say the XoTCL 0.56.3 and XoWiki 0.60 are compatible with oacs-5-2. Thank you very much for all your help.