Hello,
Currently I am evaluating A5 v10.5 (build 3553) and my focus is writing web apps that use single language, but different than English. And most problems I met were with the encoding, which is used to store the files (.a5w and .a5wcmp).
It looks like A5 store files explicitly in ANSI or some other restricted encoding. This leads to some not so nice problems.
I suppose that some of the problems could be because of my really short using of A5 (3 weeks yet).
So, does anybody else have similar problems or decisions for them?
Currently I am evaluating A5 v10.5 (build 3553) and my focus is writing web apps that use single language, but different than English. And most problems I met were with the encoding, which is used to store the files (.a5w and .a5wcmp).
It looks like A5 store files explicitly in ANSI or some other restricted encoding. This leads to some not so nice problems.
- In .a5w pages all non-ascii characters are encoded in HTML representation (&#xxxx), which is big pain if the alphabet is totally non-ascii (in my case Cyrillic). Future support and development of such pages is very hard to be done. The only chance is to use the WYSIWYG pane, which is not suitable in most cases when you need to deal with the source directly.
This is strange limitation because the Content-Type is set to �utf-8� by a <meta> tag put there by A5. I tried to not use the WYSIWYG pane and put the texts directly in the source, but obviously the file is stored in non-utf-8 encoding because on save the texts become unreadable.
. - The same problem is with most of the components. Yes, there are 3 components already (grid, tabbed ui and page layout builder), which have some kind of Multilanguage support and it can be used as a workaround (even the application is single language). But what about the Navigation component� all the characters in it (I am still talking about Cyrillic alphabet) have to be HTML encoded. You can imagine how look Navigation component in the designer with about 10 top-level options and 3 levels below. This is very hard to be managed later when you need to change something.
. - However the biggest problem is with the grid component - nevertheless it has Multilanguage support. If you have some non-ascii characters in the SQL query (by example an If() in the SELECT statement, which produces strings with non-ascii characters) then the grid is not working because it seems that on save these characters are encoded incorrectly and as a result the SQL query become invalid.
In this case even if you substitute the non-ascii characters in the query with the corresponding HTML encoding equivalents they are shown in the grid as &#xxxx, and not as expected single characters. Maybe there is a way to "force" the grid component to not encode the result returned by the SQL query, but I didn�t found a way to do that.
The only workaround for this situation were to create a view, which contains the correct SQL query (with all the non-ascii characters) and to point the grid to use that view, but this solution is really ugly.
I suppose that some of the problems could be because of my really short using of A5 (3 weeks yet).
So, does anybody else have similar problems or decisions for them?
Comment