As a side effect of the multiple window feature, we will need a new data provider type: locals.
I don’t know for you, but we are commonly using globals.myTxtVar to help in complex data entry forms. The introduction of the multiple window feature in servoy 3.5 has the side effect to render this method obsolete, as globals will display the same values for all open windows. Therefore we now need a new type of data provider: locals.
Implementation proposal:
We suggest that locals may be linked to and shared by either a form instance or a window, with the latter being may be more complex to use.
Forms locals: [forms.myForm.locals.myLocalVar]
With this implementation, locals will be referred to using formName and may display different data with any new instance of the form. Forms locals may be created either using the define dataprovider dialog (needs interface change) or as a new property for forms with the help of a specific editor or by script (although the latter method is quite non intuitive).
Window locals: [locals.myLocalVar]
With this implementation, locals will behave like plain globals with the only difference being that they will be linked to a window instance instead to the application/solution. Window locals may be created either using a new tab (locals) in the define datprovider dialog or adding a 'local’property to existing globals tab.
Case 86011 has been posted as an issue about usage of globals while in multiple windows.
Please comments and suggestions about this issue/feature?
Do you use globals as data provider to help data entry?
Does any of you fellow servoy users have a workaround for this?
We try to investigate several different ways but are blocked by the fact only columns and globals can be choosed as dataproviders. Which lead to another idea in order to solve this issue: let us set any ‘custom’ object as dataprovider (quick and mainly dirty, but will do the trick).
When you need a ‘local’, form related variable that only shows in your form there maybe sort of an alternative.
You can assign ‘virtual’ columns in your table.
These columns are in fact calculations and the only thing you should code is return;
That columns is not just form related but might do it for you.
You can use it like a regular column, values are only available in and during your current session and only within that table.
Thank you Marcel,
very interesting trick but it just wouldn’t solve the issue in a multiple windows environnement.
As values are table related, any instance of the form/window will share the same value for such a ‘virtual’ column… the same issue that we encounter with globals.
Here is a practical and simple example of the issue:
lets say we have a main form with a filter field (dataprovider == globals.myFilter) the filter is used to restrain foundset on a table view tab placed in the same form.
if we create a new instance of the window, the expected behaviour is to be able to set a different filter for the second window in order to compare data.
actually, the user will get the same result in both windows, due to the fact that the data provider is in the table/application scope.
Unfortunatly not, but we also fight with this problem
I do not think you can use any object as dataprovider as objects can return very different data.
I assume using modules doesn’t help? May be using 2 very small modules and defining globals there, which are for the whole solution not “visible” (at max a bad workaround)
Best regards, Robert
olivier melet:
Does any of you fellow servoy users have a workaround for this?
We try to investigate several different ways but are blocked by the fact only columns and globals can be choosed as dataproviders. Which lead to another idea in order to solve this issue: let us set any ‘custom’ object as dataprovider (quick and mainly dirty, but will do the trick).
In Servoy 3.5 we will have the API for getting JavaBeans to work in the Web Client. So, you could make a simple wrapper around the JTextField Bean to also work for web client. Then you can get and set data in the bean and you will essentially have Form variables.
jcompagner:
this will not made it into 3.5 because that one is almost finished.
only bug fixes will be done anymore.
Does this mean 4.0 or 3.5.x Johan ?
Anyway it is great news for us that form variables will be implemented soon.
As Gary said, we will also be comfortable with form variables being reinitialized with each onLoad event, this is expected behaviour as they are form variables, not session variables.
goldcougar:
In Servoy 3.5 we will have the API for getting JavaBeans to work in the Web Client. So, you could make a simple wrapper around the JTextField Bean to also work for web client. Then you can get and set data in the bean and you will essentially have Form variables.
Thank you for that one, as it is a real workaround. We also investigate that option prior to post the issue, but we skipped it as it proves to be very clumsy to implement in complicated forms and would prevent us (or at least render quite uneasy) from integrating seemlessly our actual standards in data entry validation.
Unless implementation of form variables will be postponed after this september, we would not consider using beans as an option. We may rather consider to postpone implementation of the multiple window feature in our solutions, waiting to be able to support it with native servoy features.