PDA

View Full Version : ALERT - Public cWebObject.ClientAction method has changed significantly



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

Harm Wibier
9-Nov-2020, 03:38 AM
This message is indeed public and it needs to be because it is part of the custom control building API. This change is part of an overall WebApp Framework improvement that we could do by switching over from the WebService end-point to the HTTP Handler. Controls can now pass custom JSON objects to the client as extra data instead of being bound to using the tWebValueTree. This does not only provide more flexibility; it also boosts performance of controls like the WebList and WebGrid.

These changes where made with backwards compatibility in mind. Backwards compatibility from the point of view of custom controls that still use the tWebValueTree, and those controls should still work (that was thoroughly tested by not migrating all the standard controls at once). We simply did not anticipate on this message being augmented.

This thread does remind me that we need to make sure that the documentation (class ref & custom controls book) catches up on these changes.
--
I do not have a clear enough view on how your multi lingual system works to give advice on how to migrate that. It feels that at the level of ClientAction you are at a very low level for what you are doing and I’d suggest to directly agument ShowMessageBox, ShowErrror instead of ClientAction.
--
We’ll fix the unused variable.