Samuel Pizarro
8-Nov-2020, 12:42 PM
CAUTION
I, just realized my sub-class layer for multi-language translation in web got broken in several parts.. when migrating from 19.1 to df 20.0
As my webapp supports multiple languages (within a single webapp.exe), the "fixed" built-in approach translation provided by daw does not works for me.
In order to support multiple-languages translations for ShowYesNo, Showmessagebox, showError, ShowInfoBalloon, ShowInfoBox, and etc.... on the client, my sub-class layer had to intercept ClientAction method. (I found no better way of doing this... If DAW has any better tip.. I would be glad to know.. )
Mainly to intercept the data that is sent to the client, and translate "fixed" terms like YES,NO,CANCEL buttons, and other diaglog captions as well.
And when converted to DF 20, realized all of the were missing the buttons. They were not even show in the client screen (not rendered at DOM)
Just realized that ClientAction has changed significantly.. So I will need off course to revisit all of it.
This method was never flagged as Private, so I just assumed it was safe to intercept it.
Previous DF releases:
Procedure ClientAction String sName String[] aOptParams tWebValueTree aOptData
DF 20:
Procedure ClientAction String sName String[] aOptParams Variant vActionData
3rd parameter has changed.
as a public method prototype has been changed.. we should have been warned about this.. things we need to be aware of, as part of our migration process. and code review.
This is a potential break for whoever was intercepting this method before.
Now, again. One from DAW may argue they were not expecting no one to be using this such lower method in the framework. I can understand that.. but the fact is, it's a public method.
I am ok, that some times public interface has to change.. But if it's done, we should be properly notified so we can review our code as part of the migration process.
And I would love to hear from DAW about other possible approaches I could use instead of this method, to support multiple languages for real.
----------------------
Side note. As part of this change, other methods that were using the old tWebValueTree structure still has the variable declared but never used anymore.
cWebApp.ShowMessageBox for example
Procedure ShowMessageBox Handle hoObj Handle hoReturnMsg String sMessage String sOptCaption String sOptLabelCSSClass Integer eOptDefaultButton String[] asOptButtons
String[] aParams aButtons
String sReturnMethod
tWebValueTree tVT <<-- old variable, still declared but not used anymore
Integer iIndex
...
I, just realized my sub-class layer for multi-language translation in web got broken in several parts.. when migrating from 19.1 to df 20.0
As my webapp supports multiple languages (within a single webapp.exe), the "fixed" built-in approach translation provided by daw does not works for me.
In order to support multiple-languages translations for ShowYesNo, Showmessagebox, showError, ShowInfoBalloon, ShowInfoBox, and etc.... on the client, my sub-class layer had to intercept ClientAction method. (I found no better way of doing this... If DAW has any better tip.. I would be glad to know.. )
Mainly to intercept the data that is sent to the client, and translate "fixed" terms like YES,NO,CANCEL buttons, and other diaglog captions as well.
And when converted to DF 20, realized all of the were missing the buttons. They were not even show in the client screen (not rendered at DOM)
Just realized that ClientAction has changed significantly.. So I will need off course to revisit all of it.
This method was never flagged as Private, so I just assumed it was safe to intercept it.
Previous DF releases:
Procedure ClientAction String sName String[] aOptParams tWebValueTree aOptData
DF 20:
Procedure ClientAction String sName String[] aOptParams Variant vActionData
3rd parameter has changed.
as a public method prototype has been changed.. we should have been warned about this.. things we need to be aware of, as part of our migration process. and code review.
This is a potential break for whoever was intercepting this method before.
Now, again. One from DAW may argue they were not expecting no one to be using this such lower method in the framework. I can understand that.. but the fact is, it's a public method.
I am ok, that some times public interface has to change.. But if it's done, we should be properly notified so we can review our code as part of the migration process.
And I would love to hear from DAW about other possible approaches I could use instead of this method, to support multiple languages for real.
----------------------
Side note. As part of this change, other methods that were using the old tWebValueTree structure still has the variable declared but never used anymore.
cWebApp.ShowMessageBox for example
Procedure ShowMessageBox Handle hoObj Handle hoReturnMsg String sMessage String sOptCaption String sOptLabelCSSClass Integer eOptDefaultButton String[] asOptButtons
String[] aParams aButtons
String sReturnMethod
tWebValueTree tVT <<-- old variable, still declared but not used anymore
Integer iIndex
...