ChicagoBoss internationalization flaws

[Tomas Morstein]

Hello,

Although we and our customers are happy with ChicagoBoss applications, there are several problems I'd like to present and discuss here:

(1) e-mail localization vs multipart vs attachments -- the problem is described here: https://gist.github.com/4437818

(2) erlydtl tags and filters seems to be not aware of multibyte encodings. Well, this has a lot of to do with Erlang itself, but it is not so good for people to easily use since many people sticked with UTF-8 whether it is . A typical case is the truncatechars filter which cuts no matter if it is whole character or not...
I think there are three possible solutions:
- add a new boss.config variable to enforce all the view variables to be treated as multibyte when it comes application of some filters (this is my preferred variant);
- try to autodetect encoding from template header (not guarantee to have such a header in there; the content may not be xml-compatible in all the cases);
- try to autodetect each string individually -- not so reliable.

(3) and another, not so i18n-related, note at the end: there are many things that are documented in the django docs, but what's not supported in CB's view processor. One of tags which I really miss, is if-elif-else-endif. It's not so common, but there're cases where it is much better than endless unreadable nesting of if-else-endifs.

Any ideas/notes/patches? ;-)

Thanks,
Tom

[Evan Miller]

On Wed, Jan 2, 2013 at 3:41 PM, Tomas Morstein <tmrf...@gmail.com> wrote:

Hello,

Although we and our customers are happy with ChicagoBoss applications, there are several problems I'd like to present and discuss here:

(1) e-mail localization vs multipart vs attachments -- the problem is described here: https://gist.github.com/4437818

Well-taken. Please open a GitHub issue on this.

 

(2) erlydtl tags and filters seems to be not aware of multibyte encodings. Well, this has a lot of to do with Erlang itself, but it is not so good for people to easily use since many people sticked with UTF-8 whether it is . A typical case is the truncatechars filter which cuts no matter if it is whole character or not...
I think there are three possible solutions:
- add a new boss.config variable to enforce all the view variables to be treated as multibyte when it comes application of some filters (this is my preferred variant);
- try to autodetect encoding from template header (not guarantee to have such a header in there; the content may not be xml-compatible in all the cases);
- try to autodetect each string individually -- not so reliable.

Also well-taken. Also worth a GitHub issue against ErlyDTL.

 

(3) and another, not so i18n-related, note at the end: there are many things that are documented in the django docs, but what's not supported in CB's view processor. One of tags which I really miss, is if-elif-else-endif. It's not so common, but there're cases where it is much better than endless unreadable nesting of if-else-endifs.

if-elif-else-endif has been supported since this summer:

https://github.com/evanmiller/erlydtl/commit/9f074aaabcdf49ae721ddfe15917bb7c65c8658d

 

Any ideas/notes/patches? ;-)

Thanks,
Tom

--
 
 

--
Evan Miller
http://www.evanmiller.org/

[Evan Miller]

On Wed, Jan 2, 2013 at 3:41 PM, Tomas Morstein <tmrf...@gmail.com> wrote:

Hello,

Although we and our customers are happy with ChicagoBoss applications, there are several problems I'd like to present and discuss here:

(1) e-mail localization vs multipart vs attachments -- the problem is described here: https://gist.github.com/4437818

(2) erlydtl tags and filters seems to be not aware of multibyte encodings. Well, this has a lot of to do with Erlang itself, but it is not so good for people to easily use since many people sticked with UTF-8 whether it is . A typical case is the truncatechars filter which cuts no matter if it is whole character or not...
I think there are three possible solutions:
- add a new boss.config variable to enforce all the view variables to be treated as multibyte when it comes application of some filters (this is my preferred variant);
- try to autodetect encoding from template header (not guarantee to have such a header in there; the content may not be xml-compatible in all the cases);
- try to autodetect each string individually -- not so reliable.

Well -- in the meantime for truncatechars I think it's better to produce a potentially incorrect result for non-UTF-8 (i.e. too many characters) than a potentially invalid result for UTF-8 (i.e. characters cut in the middle of the encoding). Here's a patch implementing UTF-8-aware truncatechars, inspired by Seven Du's work:

https://github.com/evanmiller/erlydtl/commit/c18f2a00c2dcf75c2ab7370983f9f0873a06fd9f

Are there other problematic filters/tags?

 

(3) and another, not so i18n-related, note at the end: there are many things that are documented in the django docs, but what's not supported in CB's view processor. One of tags which I really miss, is if-elif-else-endif. It's not so common, but there're cases where it is much better than endless unreadable nesting of if-else-endifs.

Any ideas/notes/patches? ;-)

Thanks,
Tom

--