Strange parameters passed to globalmethod-based valuelist

Classic Servoy
1

I’m seeing some strange input values to my valuelist based on a global method. All testing and behaviour documented below is with Servoy 5.2.3 and Webclient.

  1. When the value in the underlying database table is null then the realValue passed into my global method is “-1”. With Smartclient this doesn’t happen so this is likely a bug? Created case #342983 for this.
  2. When entering find mode my global method is called three times:
  • First with null displayValue & realValues along with a record filled with null values (this makes sense).
  1. Secondly with null displayValue & realValues along with a record parameter that is not a JSRecord at all. It seems to be some sort of “State” object. This is completely undocumented but does allow me to detect when entering find mode so I can return a custom valuelist for find mode (important for my use case).
  2. Finally my global method is called again with a null displayValue & “-1” as the realValue (this appears related to 1 above) and the record parameter is again the strange “State” object mentioned in b.

Unfortunately, no mention at all is made of find mode in the sample code. Since the behaviour of 2b above isn’t documented I don’t know whether this is a feature I can rely on or merely a bug (being able to differentiate when in find mode is important because I need to return a different valuelist based on whether I’m in find mode or not.)[/*:m][/list:o]

Hopefully someone can shed some light on this.

Thanks,
Corey

2

Yeroc:
hen the value in the underlying database table is null then the realValue passed into my global method is “-1”. With Smartclient this doesn’t happen so this is likely a bug? Created case #342983 for this.

yes this is a bug, there shouldn’t be a call to the method when the dataprovider is null definitely not a -1.
This is fixed for the next release of 5.

Yeroc:

  1. When entering find mode my global method is called three times:

  2. First with null displayValue & realValues along with a record filled with null values (this makes sense).

  3. Secondly with null displayValue & realValues along with a record parameter that is not a JSRecord at all. It seems to be some sort of “State” object. This is completely undocumented but does allow me to detect when entering find mode so I can return a custom valuelist for find mode (important for my use case).

  4. Finally my global method is called again with a null displayValue & “-1” as the realValue (this appears related to 1 above) and the record parameter is again the strange “State” object mentioned in b.

Unfortunately, no mention at all is made of find mode in the sample code. Since the behaviour of 2b above isn’t documented I don’t know whether this is a feature I can rely on or merely a bug (being able to differentiate when in find mode is important because I need to return a different valuelist based on whether I’m in find mode or not.)[/list]
[/quote]

the first one is removed (that didn’t make sense to do that call, its a very special state to clean up the ui, we call it ProtoType state)
so i made sure that for that it isnt called anymore

the last one is removed because of the first thing i fixed for you first point.

What you do get is the second thing, and this one is just correct, i improved its representation in the debugger a bit, instead of “State” it will give you “FindRecord” in the variables view, by default it will also list all columns that the table has where this find record is on. So it displays now quite the same as a normal record. (and in this situation with all null values)

But yes it is not a JSRecord because currently FindRecords don’t have the same methods as the JSRecord has, like isEditing() or getPKs() which don’t make any sense for a FindRecord. This record is exactly the same as you get in scripting if you would do:

foundset.find()

var record = foundset.getSelectedRecord()
// now record is also a FindRecord not a DataRecord (== JSRecord)
foundset.search()

3

Thanks Johan. So code like this should work going forward:

function getDataSetForValueList(displayValue, realValue, record, valueListName)
{
  var isInFindMode = !(record instanceof JSRecord);
  ...
}

It would be nice if at some point an explicit parameter were added to signal that we’re in find mode. Our use case is that all our reference tables/value lists have records that may be marked inactive. Naturally, when a value list record is marked inactive existing records may still have references to the inactive values so they need to be displayed (this could be implemented using fallback valuelists) but when editing a record only the current value and active values should be available and when in find mode ALL values (including inactive) must be available so that inactive values may be queried. Maybe there’s a better way to tackle this requirement?

Thanks,
Corey

4

yes that will work it is the same as doing this:

	application.output(foundset.getSelectedRecord() instanceof JSRecord)
	foundset.find();
	application.output(foundset.getSelectedRecord() instanceof JSRecord)
	foundset.search()

there you will have the same result (true and false)

Yes what you describe is why we have now fallback valuelist, only that fallback list is not used currently in findmode. This could be a nice option to have somewhere i guess.
Don’t know currently where you would say that but i guess in the valuelist dialog when you assign a fallback list then you also there have a checkbox “use as primary in findmode”

Then you should be able to use for example a global valuelist that has as fallback a normal “all table values” valuelist (or related valuelist)

EDIT: skip the case for the find mode fallback, this is already the default right now. So you can have a global method valuelist that only works in browse mode that has an other valuelist attached that is used in find mode (or used when in browse mode when there is a real value that is not resolved by the normal valuelist)

But also having a find mode boolean is also fine, can you create 2 cases for this?

5

Thanks Johan,

For some reason I didn’t think to check whether fallback valuelists were used in find mode. Hopefully that bit of information will find its way into the documentation. :wink:

I’ve created case #343765 to add an explicit boolean parameter to the global method indicating whether find mode is active or not.

What do you think about making it so global methods can also be used for related valuelists? This is an important issue for us as well. You implemented case #332485 (support for dependent value lists in find mode) but with this new requirement to support deactivated reference values we now need to use global methods for related valuelists as well and have them fire etc. Any thoughts on this? I think at a minimum (aside from changes to the UI in Serclipse) we’d need to have the “parent” valuelist and selected value passed into the global method as well.

Corey

6

i dont know exactly what you mean with “What do you think about making it so global methods can also be used for related valuelists?”

but a parent valuelist what do you want to do with that?
A valuelist is just a bunch of values, it doesnt hold the selection.
For example that related depended valuelist don’t depend on the valuelist values of the “parent” valuelist
It depends on the dataprovider’s value that has the valuelist attached.
The selected value can also just be get from the record object passed in (also in find), but i guess you don’t know which dataprovider that is? (and related valuelist know this thats why they work)

7

jcompagner:
i dont know exactly what you mean with “What do you think about making it so global methods can also be used for related valuelists?”

We need a way to say valuelistA is dependent on, and/or related to, valuelistB even in the absence of a concrete database relation so that Servoy knows to call the global method on valuelistB when the selected value for valuelistA changes. As far as I can tell there’s no way to accomplish this today.

jcompagner:
but a parent valuelist what do you want to do with that?
A valuelist is just a bunch of values, it doesnt hold the selection.
For example that related depended valuelist don’t depend on the valuelist values of the “parent” valuelist
It depends on the dataprovider’s value that has the valuelist attached.
The selected value can also just be get from the record object passed in (also in find), but i guess you don’t know which dataprovider that is? (and related valuelist know this thats why they work)

I’d prefer to see the parent valuelist along with the currently selected value (realValue, displayValue) passed in in the same manner as it is currently for the main valuelist since as you pointed out my global method won’t know the dataproviders to check (well, it could, but it would make the code a lot more complicated to have to figure it out.) We have a number of cases where the same valuelist is used on different tables with different provider names so it would be a headache to have the code figure that out – Servoy already knows what the current realValue and displayValue is for the parent valuelist so it would make life easier if it would pass it in.

Thanks,
Corey

8

So we have to pass in 3 more values in a “child” valuelist?
1> the parent valuelist
2> the real value
3> the display value

Besides the configuration option in the valuelist (when it is a global method valuelist) to be able to set the parent
You could open a case for this to see if we can come up with a nice solution.

For now you can mimic this behavior by, create your global method that has all the logic but with the extra arguments
Then create a valuelist per dataprovider that needs this and call another global method that does nothing more then calling the other global method but then with hard coded 3 other values.
Thats not that much work and all your logic is still in one place.