[Openinteract-dev] Experiences with OI2 1.99_06

[Teemu A. <te...@io...>]

Hello,

I ported my applications from 1.99_04 to 1.99_06.

A couple of things that I had problems with:

1.
task_name and action_name are not anymore in CTX->request. Is there
other way to access those through the context?

2.
My stock debian apache2 with mod_perl2 segfaults after the APR::Table fix.
Haven't checked any further.

3.
If you have packages that use spops objects from one and another, you can't
remove all of the packages with the remove_package manage task, you only end up
breaking things. That's because oi2_manage doesn't work anymore if the package
classes do not include properly (i.e., SPOPS class is missing). You have to manually
edit repository.ini

4.
Why not introduce a parameter for remove_package that also deletes the package
directory in pkg/[package_name-version]? You can't reinstall the package again
with the same version once it has been removed, you have to remove the directory
in pkg/ first. A parameter to do this at the same time would be nice.

5.
The user sometimes receives the following message instead of the page one
is browsing:
Failed to save error object: Cannot overwrite existing file
/usr/local/oi/error/2005-03/22/071417-000.txt with error contents at OIAppender.pm line 52.

So the application kinda breaks. Maybe it happens if you receive two errors at the same time?

6.
I had to modify some of the OI2 source code. I did not commit any of these to the CVS,
because I need to know what you think. Attached is a patch to OI2 1.99_06 with some
changes I had to do:

lib/OpenInteract2/I18N/Initializer.pm
Well formed .PO file looks like this:

---
msgid ""
msgstr ""
"Project-Id-Version: Dicole\n"
"Last-Translator: Teemu Arina <te...@di...>\n"
"POT-Creation-Date: 2005-03-22 02:06:45+0000\n"
"PO-Revision-Date: 2005-03-22 02:06:45+0000\n"
"Language-Team: Dicole <in...@di...>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Dicole\n"

msgid "Add folder"
msgstr "Add folder"
...
---

It has a header with a null msgid that tells something about the content
of the translation.

OI2 Initializer.pm does some black voodoo magic with Template toolkit
to build %Lexicon in the new class. This breaks because the msgstr of the
header has a set of new lines. Anyway, is this TT hack really that necessary? Think
if we move to UTF8 support later, this Template toolkit hack will break things
(utf flags, I guess). Is there a better way (not copying the msg variables)?

Another problem with the TT stuff is once again the way it constructs the key
of the hash. It doesn't take into account that the key might contain characters
like ' or \. Also, msgstr ending in \ or strings containing {} will also break
the TT hack.

My patch is a quick hack fix to some of the above problems (removes null msgid
key completely, fixes the TT stuff a little bit) but a more robust solution
should be written.

Also, my patch removes unnecessary dublicate key errors. If you use strings
as keys, you most likely end up with dublicate key errors with common strings because
all the strings are global in OI2 (fix coming soon?). This is not life threattening but
useful to developers, so I moved the error from warn to debug (logs in end user installations
should not fill up with errors like this).

lib/OpenInteract2/I18N.pm
Changes the system so that instead of returning "Message error for '$key'"
it returns the key itself in case no translation is found.
This is to ensure that in incomplete translations the english version is
displayed instead (if you use strings as keys instead of some ID values).
There are perfectly good examples when you might want to run some strings through
_msg and the strings will return them selves if no translation is found.
Also moved from warn to debug the information of untranslated strings.

This is once again, only useful information for developers.

lib/OpenInteract2/Request.pm
OI2 always selects the language provided by the browser (user agent). Well, it was a bit
difficult to change the language as a user, because it had no effect ;)
I changed this chain to something more logical:

Changes the order in how the language is selected:
 - prefers $lang_config->{choice_param_name} over user or session language
 - prefers user and session language over user agent provided languages
 - prefers everything else over $lang_config->{default_language}


Regards,

Teemu Arina, CTO

Ionstream Oy / Dicole
Komeetankuja 4 A
02210 Espoo
FINLAND
Tel: +358-(0)50 - 555 7636
skype: infe00
Corporate website: http://www.dicole.com
FLOSS in education blog: http://flosse.dicole.org
Personal weblog: http://infedelic.blogspot.com

"Discover, collaborate, learn."