Re: [Openinteract-dev] Experiences with OI2 1.99_06

[Chris W. <ch...@cw...>]

* Teemu Arina (te...@io...) [050321 20:50]:
> I ported my applications from 1.99_04 to 1.99_06.
> 
> A couple of things that I had problems with:

Thanks for posting these, they're very helpful.

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

Why do you need them? I thought of keeping them in the request after
implementing the ActionResolver but couldn't think of a good
reason. (And that's not saying there isn't one.)

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

My mp2 experience is lacking as well.
 
> 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

I think a change I made to the 'install_package' management task would
help here -- instead of creating the context and running all setup
tasks it skips 'read packages'. (This was in response to similar
problems raised in OIN-147 and OIN-148.)

I'll give this a shot with 'remove_package' and see how it goes.

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

Great idea -- I'll create an issue for it.

> 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?

Yeah, within the same second. DateTime apparently doesn't store
milliseconds properly (or maybe we have to use Time::HiRes somewhere?)
and that's what the '-000' on the end is supposed to be using.

I'll add an 'if exists then change name' check in the error storage
function.

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

The PO parsing is done entirely in Locale::Maketext::Lexicon::Gettext,
so if there's a bug in the parsing we should probably let them know.

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

Hmmm... well, I don't think it qualifies as black voodoo magic, but I
see your point. We may just want to do something like:

  - create classes for all supported languages
  - assign keys/values directly into created class

That way there should be no modification of the original variable and
it will maintain its utf8 (or other) metadata.

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

I think the proposition above should take care of this.

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

No problem, I didn't know how often this sort of thing happened.

The global string issue is slated for fixing and I had some ideas on
how to do it:

  http://jira.openinteract.org/browse/OIN-29

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

That makes sense.

> 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}

That makes sense too. If you've got these on your system already why
don't you go ahead and commit them? If not I'll patch and commit.

Thanks!

Chris
 
-- 
Chris Winters (http://www.cwinters.com)
Building enterprise-capable snack solutions since 1988