In Pivot Table JS functions, we are forced to use the localized name of a property, even if not using the “localizedName” for a property, it is taken from messages.properties file.
Sample project attached: invoiceLine.date returns null while invoiceLine.DateLoc returns the date correctly. (DateLoc is defined in the messages.properties)
Which means the code outcome depends on what you have in your messages.properties files, this is dangerous.
If a user connects with another locale, pivot is broken. If one day a client asks to change a display label for a field, same. And I did not test with labels containing spaces, which obviously can happen in localizations.
If “localizedName” ought to be the solution, it means localization is hard coded…
This is not developer friendly, and, worse, I wonder how we can use this component in a multi-language application.
Or am I missing something ?
testcuba.zip (158.8 KB)
You’re right, that’s not convenient, but that’s restriction of pivottable.js library. In case of multilanguage, I would recommend writing JS functions in
message.properties files and set them programmatically. For example, take a look at this online demo.
Understood, integration point between CUBA and pivotable.js is before computation only, so you need to process localization before.
However I think that it would be possible with a modified version of pivottable.js that would apply localization based on messages.properties files after computation instead of before. This way you keep coding with attributes like everywhere else, much more consistency.
This implies implementing part of CUBA messages infrastructure in JS. Quite sure some JS ninja out there could make it.
Having the code split between xml, java and now localization files is too cumbersome for us. It means you have to test your code in each and every localization. Localization should impact display and nothing more.
Plus, having an integration point post-computation would allow CUBA to implement other features like drill-through, in financial world this is a highly requested feature (and we need it), maybe an idea for the roadmap ?
We have thought about setting up Pentaho now that it is available in CUBA (which is a great move BTW) but we don’t want yet another “moving part” just for a few agregations, maybe later.
In the meantime, we have started developing our own lightweight implementation in pure Java/CUBA, generating JQPL “group by” on the fly. This is a middle-range use case for pivot tables between agregating in front-end (flex monster, pivotable.js) and a BI setup.