Forum OpenACS Development: xowiki 0.39

Collapse
Posted by Gustaf Neumann on
i have just committed a new version of xowiki to CVS head that contains the two new package parameters package_prefix and use_connection_locale to control the generation of links in xowiki.

XoWiki constructs now links as compact as possible. So, if the locale is set e.g. to en_US, and a page is named en:page, the link will be now //hostname/xowiki/page instead of //hostname/xowiki/en/page. It can be compacted further to //hostname/page, when package_prefix is set to /. When use_connection_locale is set to 1, //hostname/page will deliver different pages depending on the locale setting of the browser, if possible.

For details, see the updated section in:
http://media.wu-wien.ac.at/download/xowiki-doc/#config

Note that only one package instance can set package_prefix to / and that this setting makes only sense with an appropriate index.vuh file. Since .vuh-files are used as last resource, one has to be careful with the naming of the pages mapped to the top directory to avoid name clashes with other preexisting urls. I run as well into the problem with the new image handler of Dave //sitename/image for mapping image files of xowiki. For he time being, xowiki ignores the package_prefix for images and files. Alternatively, Dave's directory could be named //sitename/images or the like...

Collapse
2: Re: xowiki 0.39 (response to 1)
Posted by Malte Sussdorff on
I gave it a try (connection_locale) and it works just beautifully. Sadly, I have to call the page name individually like this:

http://cognovis.de/unternehmen2/index

If I just use
http://cognovis.de/unternehmen2/ (which is the package root) it will send me to the en:index page, despite the fact that I set the index page parameter to de:index.

Any idea why that could be?

Collapse
5: Re: xowiki 0.39 (response to 2)
Posted by Gustaf Neumann on
Malte,

i tried your setup on my machine, but i can't reproduce what you are reporting. The code works just fine. Let us assume

  • package parameter index_page: index (or empty, "index" is the default)
  • package parameter use_connection_locale: 1
  • browser setting: language de
  • server setting (system locale): en
  • xowiki mounted as: xowiki
  • You have a page named de:index and a page named en:index
if you browse to http://.../xowiki/, you get the german page (de:index). If you set your browser-setting to russian, you get en:index, the same happens if you set the browser setting to english....

What's different on your site?

Collapse
9: Re: xowiki 0.39 (response to 5)
Posted by Malte Sussdorff on
Somehow my setup seems to be screwed up, but I don't know how:
  • package parameter index_page: empty
  • package parameter use_connection_locale: 1
  • browser setting: language de_DE
  • server setting (system locale): de_DE
  • xowiki mounted as: xowiki
  • package_prefix: /
  • You have a page named de:index and a page named en:index
  • I have a page de:company but I do NOT have a page en:company

This is my /web/cognovis/www/index.vuh:

# -*- tcl -*-
::xowiki::Package initialize -ad_doc {

This is the resolver for this package. It turns a request into
an object and executes the object with the computed method

@author Gustaf Neumann (mailto:gustaf.neumann@wu-wien.ac.at)
@creation-date July, 2006
@cvs-id $Id: index.vuh,v 1.5 2006/09/15 16:45:00 gustafn Exp $

} -parameter {
{-m view}
{-folder_id:integer 0}
} -url /xowiki[ns_conn url]

::$package_id log "--starting... [ns_conn url] [ns_conn query] \
form vars = [ns_set array [ns_getform]]"
#::$package_id exists_form_parameter creator
#::$package_id log "-- [::xo::cc serialize]"

::$package_id reply_to_user [::$package_id invoke -method $m]

::$package_id log "--i ::$package_id DONE"
ad_script_abort

Now I browse:

What confuses me now is the fact that it does not default back to de_DE, which is the system wide locale as set in /acs-lang/admin. I managed to fix the fallback by adding the following code to Package instproc resolve_request {-path} { (right after the last if {$item_id == 0} statement where you try the normalized name:

if {$item_id == 0} {
set nname [my normalize_name $name]
set item_id [::Generic::CrItem lookup -name $nname -parent_id $folder_id]
my log "--try $nname -> $item_id"
}

######## New code begins here ############

util_user_message -message "Content is not available in your locale"

# Item is still empty, try default language for the package
if {$item_id == 0} {
set system_locale [lang::system::locale]
set lang [string range $system_locale 0 1]
set name ${lang}:$local_name
set item_id [::Generic::CrItem lookup -name $name -parent_id $folder_id]
}

# Item is still empty, try default language for the site
if {$item_id == 0} {
set system_locale [lang::system::locale -site_wide]
set lang [string range $system_locale 0 1]
set name ${lang}:$local_name
set item_id [::Generic::CrItem lookup -name $name -parent_id $folder_id]
}

###### New code ends here ########

This results in the (desired) behaviour, that if the content is available in site locale, the site locale is presented, yet the navigation (categories portlet) still only shows the pages which are available in this language. Additionally the user notification shows up.

Maybe this should be made a switch (DefaultToSiteLocaleP) but I won't commit anything anyway until Gustaf could take a look.

Still, the index page is a mistery to me....

Collapse
10: Re: xowiki 0.39 (response to 9)
Posted by Malte Sussdorff on
The util_user_message needs to go within the if statement, not right before (otherwise it shows up all the time, which does not make sense). I modified it a bit to allow automatic creation of new pages:

          # Item is still empty, try default language for the package
          if {$item_id == 0} {
              set new_url [export_vars -base "/xowiki/" -url {{edit-new 1} {return_url [ad_return_url]} {object_type "xowiki::Page"} {na\me $name}}]
              util_user_message -message "Content is not available in your locale. Create <a href=\"$new_url\" target=new()>new</a>" -ht\ml
              set system_locale [lang::system::locale]
              set lang [string range $system_locale 0 1]
              set name ${lang}:$local_name
              set item_id [::Generic::CrItem lookup -name $name -parent_id $folder_id]
          }

What I found interesting though is that if I unpublish the item in question (e.g. en:company), the page is still showing up the en:company page, instead of (as I would have assumed) the de:company page with the user notification. If I delete the page in question all is fine.

My assumption is that ::Generic::CrItem lookup -name $name -parent $folder_Id does not query for published items and could use a "-live" flag to query only items which are live. But I won't dive down into these waters :).

Collapse
11: Re: xowiki 0.39 (response to 10)
Posted by Gustaf Neumann on
malte, before i look into the details: can it be, that a setting in the folder_object like

set index_page "en:index"

causes the confusion?

-gustaf

Collapse
12: Re: xowiki 0.39 (response to 11)
Posted by Malte Sussdorff on
Yeah. You were absolutely right. That was it. Now I know: First check the folder object than check the parameters... Maybe we could have a warning on the parameters page like "YOU HAVE TO CHECK THE FOLDER OBJECT HERE" 😊.

I could not figure out in the documentation if you can say in an xowiki page directly which folder object to use, so you could have different settings depending on page. I solved this so far by just mounting a different xowiki instance (http://www.cognovis.de/developer) which is only available in English and therefore has different settings in the folder object for language etc.. Did I do this unnecessarily ?

Collapse
3: Re: xowiki 0.39 (response to 1)
Posted by Malte Sussdorff on
My suggestion for handling the index page is as follows:

if there is no value in index_page parameter:
- Check for the locale (default_language) and return the appropriate xx:index page, where xx is the lang
- If there is no xx:index page for this locale, fall back to system_locale::index

if there is a value in index_page parameter:

- If the value is like xx:mypage, then return the xx:mypage, meaning in the locale which is given by "xx"

- If the value is "mypage", then return mypage in the locale of whatever default_language returns, or fall back to the system_locale version of the page.

Collapse
4: Re: xowiki 0.39 (response to 1)
Posted by Malte Sussdorff on
Yet another question: how can I set the context bar to be included in the template? If I modify oacs-view.adp to include the context_bar somewhere, where would I put the code to generate the contact bar into? Or should I not bother and just to TCL execution in the adp page?

Sorry for asking so many questions now, but with your recent change you pushed me over the edge to finally get rid of ETP and use XOWiki for our homepage as well and this really is looking great already!

Collapse
6: Re: xowiki 0.39 (response to 4)
Posted by Gustaf Neumann on
i am not sure, i understand your question. One can use different templates for xowiki, xowiki provides support for specifying e.g. package specific templates. one sample template is oascs-view, but this is not the default. I put this in to make the update on oacs.org simpler. you can use certainly different templates, like everywhere in openacs.

context-bar: normally, this is set in the site master, i am sure, you know this. the curriculum bar is set as well in the site master, the dotlrn toolbar is in blank-master. i never tried to understand the logic what is supposed to be in what master, in learn, we have simplified this drastically to one master template. Btw, what is contact bar?

why no use all the site template or the master template?

Have you sorted out, what i believe is a configuration problem on your site (your other question in the thread)?

Collapse
7: Re: xowiki 0.39 (response to 6)
Posted by Malte Sussdorff on
My question is as follows.

http://cognovis.de/solutions contains an xowiki page. In this xowiki page you have the part with "Search" and "Index" which comes from xowiki (I stole this). Now, on the left side I want to get the context bar, which is usually set in the site-master.tcl, but which i have taken out of site-master because I do not want it on top or at the buttom of my page, but exactly in the middle.

The right bar and "Unternehmen" "Lösungen" line comes from cognovis-master.

The left bar and the image along with the xowiki code comes from /templates/xowiki/cognovis-view (I have a different structure for templates on our sites, as we are using a custom package for each customer (e.g. /packages/cognovis/) and have a template directory there to hold all the various templates in one place to be changed.

THerefore I need to get the generation of the context bar into Page instproc view (or so I thought). Here is the code which will set a multirow "context" in the callers environment.

# Context bar
if { [info exists context] } {
set context_tmp $context
unset context
} else {
set context_tmp {}
}
ad_context_bar_multirow -- $context_tmp

Sadly adding this to "Page instproc view" along with putting the context_tmp to the variable section did not have the desired result, as context would not be set / passed on (server error).

I do need the multirow though to create the breadcrumb trail as shown in site-master.adp.

So basically I am stuck at the moment, at least I am stuck there :).

With regards to the multilingual problem for the root site, no I did not figure this out yet. Will do hopefully tomorrow.

On a related note I realized that the categories.tcl will display both "de:solution" and "en:solution" in the menu if both are present, instead of presenting the link to the file which is there in the language of choice (and only to this file and not to the other languages as well). Again, something I will look into tomorrow.

Collapse
8: Re: xowiki 0.39 (response to 7)
Posted by Gustaf Neumann on
without looking into the details: if you use for an xowiki instance a custom adp template, you can add at the appropriate place an adp-include into the .adp file containing the bars. i guess, this is the cleanst solution for what you are describing.

when you change the view method - which i would not recommend in your use case - be aware that xowiki passes explicitely the variables as context to the template (if you want, the reverse part of a page contract) in return_page.

none of the includelets are designed to filter out some content in some languages depending on preferences. If this is wanted, it should be done on the SQL layer, since e.g. the categories includelet supports e.g. counting; if you know an efficent way to do this in SQL, we can add this to xowiki. if you are looking for a quick solution for your site, i would recommend to alter the category renderer in the portlet procs to filter out the stuff, you do no want. But please, DON'T commit this to CVS.