How to access globals and related dataproviders
Published by admin on Tuesday, August 11, 2009 - 05:47:44 - Filed under General, News
I had some nice info from Johan Compagner on the Tano forum, it helped me fix the DateChooserBean’s way of dealing with the globals, - that Gary Dotzlaw also noticed -, because the onDataChange event was not firing correctly when using globals.
I was thinking along that line:
To access a dataProvider’s value by its name, I needed to check if it was contained in the Foundset, so giving that I had access to the record (given by Servoy in the setSelectedRecord() method of the IServoyAwareBean interface), I could then get the IFoundSet using getParentFoundset() of the IRecord interface. Fine for record’s dataprovider (the one from the form’s foundset).
Then I could see in the 5.x public API that the IFoundset was extending the IGlobalValueEntry interface where I could use getDataProviderValue() and setDataProviderValue(), as well as containsDataProvider to test it beforehand. I thought that this mean that I needed to get the foundset to get a global. It seemed logical, knowing that the IRecord interface only have getValue() and setValue() and seems to have no knowledge of the IGlobalValueEntry interface.
Still, nowhere could I see the getter/setter for the related dataProvider values. There is a getRelatedFoundSet(String relationName) in the IRecord interface, but you still need to provide him with the relationName (and possibly recursively gain access to the end FoundSet, but that was going to be tiresome, plus involving some parsing of the dataProvider String…
When in fact, according to Johan, the answer is much simpler even: to access a global, you can retrieve it’s value directly from the IRecord.getValue() and set it through the IRecord.setValue(), and to access a related record’s value, you can do the same. The trick is to use the whole String (including “globals.” or “relationName.secondRelationName.”) in front of the name of the field. The parsing is done by Servoy in the IRecord object instance itself!!!
I tried it and it works really well, in Servoy 4.1.x and more (the IRecord interface was not public in 3.5.x).
So I updated my methods to use this simple trick and it also fixed the problem with the onDataChange events not fired on globals in the DateChooserBean!
And of course, I will update the bean tutorials - in upcoming part 8 -, to reflect this new version of dataProviders access.
Once again, I am amazed at the power hiding between one simple line giving the name of a method in an interface of the public API.
If only this power was a little bit documented!!!
But then, this is where I come in would you say…
And all the time I scratch my head in front of these simple method names and try to imagine what they can do, and perform hundreds of bold or silly tests that fill my workspaces with numerous test classes and impossible solutions, and crowd my Servoy log with a long list of Exception stack trace, and haunt the forum in search of the missing information, this time is all the less you will have to spend to get the juice of this powerful public API, and get the best of this powerful app that keep getting better and better…
Some days, I feel like a philantropist ;-)
