PS - In case anyone is wondering, I'm using the JSON parser from here:
The only thing I've had to change in the code for it so far, is this small function:
Public Function Collection()
set Collection = Server.CreateObject("Scripting.Dictionary")
End Function
Just remove the "Server." part. It's not required in TC. So it simply becomes:
Public Function Collection()
set Collection = CreateObject("Scripting.Dictionary")
End Function
I've only been using it to read thus far. Haven't tried writing with it yet. But the iterable object returned for a read action seems to be spot on. Saved me a lot of work!
(And I'm much more familiar with VBScript, hence why I'm using it for the Script Extensions - in case anyone thinks I'd be better using Jscript)
Was still searching after posting this. This post:
Mentions some disadvantages to Script Extensions. Number 1 being they can't reference other script units.
Can someone (either who has used it or staff/mod) confirm? If this is the case, my parser will have to live in the same extension unit as all the TFS functions. I'm starting to set up the TFS functions now (I write all the VBScript as a normal TC project then ship it out to create the TCX file for the extension) so I'd rather not have to restructure it and change all my class declarations if I can't separate the two .....
Thanks again!
Script Extensions can't use script units, that's true.
But of course, Script Extensions can use other scrípt extensions, so modularization is not too difficult.
Another point is, that Script Extensions can't use all of the libraries available in script units.
As a workaround, references to the missing libraries can be handed into the Script Extension e.g. via an initialization routine and stored there on a module-global level. After using the Extension, they should be reset to Nothing in a shutdown routine.
Initialisation and shutdown can be done in event routines
GeneralEvents_OnStartTest, GeneralEvents_OnStopTest
Regards,
Manfred
"But of course, Script Extensions can use other scrípt extensions, so modularization is not too difficult."
Yeah. I know they can call each other. I already do that with some other extension scripts.
But in the case of a VBScript custom class, does this mean I have to make the helper function avilable as a method of the extension containing the custom class declaration? In order for the other extension units to be able to call it?
In TC VBScript, a custom class instance can only be declared in the unit it's scripted in.
If another unit wants to use an instance of the class, it has to call into a "helper" function of the unit containing the custom class, and the function will pass back the class instance as the response. This is normally (in a standard script unit), done via the USEUNIT statement.
But I don't think that works in Script Extensions?
So for Ext-Unit 2 to get a custom class instance back from Ext-Unit 1, Ext-Unit 1 needs to make the function available to call in to retrieve the instance?
So if my helper function lived in "Unit1" and was called "Helper1", to get an instance of my class in unit 2, I would need to enable calls to Unit1 from unit 2 and then have something along the lines of:
Set NewThing = Unit1.Helper1
I can't just do:
USEUNIT Unit1
and
NewThing = Helper1
I wanted the class creating module to be self-contained within the extensions. I don't need, or want to make it available outwith the other extension units which will be using it. I suppose, I don't need to set up the code complete XML for it as I don't want it being used outwith the framework extensions.
Extension units effectively form a test framework for me. This is new functionality to extend our framework further ....
