Has someone worked in the possibility of having blog entries in many differente languages? I have been studying the lars-blogger datamodel in order to do so and it doesn't look like an easy task to be donne. I have to be able to store the locale for the entry, wich doesn't seem to be the worse thing, but the same entry_id must have different contents for each language.

My idea was to create a different table with the same contents from the pinds_blog_entries table, but with the locale option and another primary key, and also changing the structure of pinds_blog_entries table. I would have in the first table the entry_id (acs_object) and an auxiliary id wich would refer to the other table where the entry contents would be. So, instead of one I would have two tables for the entries.

However, I'm a little afraid to do that because it would change the whole db relationships (such as the search datasource), and I would have to find out the the "black holes" to fix.

I can't see how to do it without change the package datamodel. Has anybody worked on that and have a better idea?

Hey Malte,

Can you put your scripts in CVS, maybe in contrib, or otherwise make them available?

Note that in my script I "loose" the publish_date as I'm not sure support for this exists in XoWIKI so far.

You can just make a new "news-portal" which instantiates a second XoWIKI instance in the community, wouldn't that help? Like dotlrn-xowiki-news or something in that line.

I am just concerned you are going to put a lot of effort into something which could be solved with less effort differently.

Changing the datamodell is not the hard part, getting the multi language bit right seems to be more of an issue for me at least. And with XoWIKI you also get "Teaser" support, which allows you to display a different text on the summary page then is on the actual full page (instead of the 50 first characters or whatever you have configured).

I think that Gustaf made some changes so I should revisit my "move" scripts. Sadly I'm on "holidays" so I wont get to this as quickly as I'd like to. If i have an idea tomorrow morning I will post, otherwise maybe Gustaf can help.

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 http://www.xotcl.org

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.

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.

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.

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?

one more question: what version of postgres are you using?

Eduardo,

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

Hi everybody,

I'm facing some troubles with the lars blogger migration script, mine above or Cognovis' in the address http://www.cognovis.de/developer/en/xowiki-upgrade-lars-blogger.

I'm using the latest XoWiki and XoTcl versions (0.95 and 0.90) and it seems like the script is broken. I've tried to change the script like this:

# Change the following variables to suit your environment
set pinds_package_id 3900
set xowiki_package_id 4345
set xowiki_folder_id 4368

db_1row template "select item_id as page_template, parent_id as xowiki_folder_id from cr_items where name = 'en:news-item' and content_type = '::xowiki::Form' and parent_id = :xowiki_folder_id"

## Do not change anything below

set import ""
db_foreach pinds_entry {select creation_user, creation_ip, creation_date, entry_date as last_modified, p.title, title_url as detail_link, content, content_format, draft_p from pinds_blog_entries p, acs_objects o where p.entry_id = o.object_id and p.package_id = :pinds_package_id} {

# Set publish status
if {$draft_p} {
set publish_status "production"
} else {
set publish_status "ready"
}

# Text conversion
if {$content_format ne "text/html"} {
set content [ad_html_text_convert -from $content_format -to "text/html" $content]
}

set item_id [db_nextval acs_object_id_seq]
set creator [person::name -person_id $creation_user]

set import "::xowiki::FormPage create \
page_template $page_template \
creator $creator \
instance_attributes {detail_link $detail_link} \
description {} \
text {$content} \
package_id $xowiki_package_id \
name $item_id \
title $title \
publish_status $publish_status \
last_modified $last_modified \
parent_id $xowiki_folder_id"

}
if {[catch {namespace eval ::xo::import $import} error]} {
set msg "Error: $error"
} else {
set msg [$xowiki_package_id import -replace 0]
}

But I keep seeing this error message:

invalid command name "4345"
while executing
"$xowiki_package_id import -replace 0
"

I've tried to find out, but I don't know where it's coming from. Can you help me on this?