Some notes on creating a minimal DataFlex library workspace (generally of classes, but often other source files as well) that can then be accessed by developers using the “Add Library…” feature of the DataFlex Studio.
’Twas the night before Christmas, when all through the house
Not a creature was stirring, not even a mouse;
’Cept a lonely old programer, building a library… (ed: that doesn’t even scan, let alone rhyme!)
OK, Mr Grumpy, perhaps I can offer you Verity Stob’s rather excellent pastiche of Robert Frost’s “Stopping by Woods on a Snowy Evening” instead:
Porting An Old Library Late One Evening
Whose C this is I think I know:
I made it many moons ago
When I was young and full of passion
And K&R was all the fashion.
Strange beauty here. I see the traces
In overhanging curly braces
Of long-forgotten big ideas
My hopes and thoughts of former years.
My little Compaq stirs her drive
As if to say, Hey! Look alive
For goodness’ sake pull out your finger
We do not have the time to linger.
I close the file with little zest.
I’ve many modules yet to test,
And code to write before I rest,
And code to write before I rest.
So… enough of the poetry already!
I have long been frustrated with a problem in delivering a library (generally of classes, but often other source files as well) as a workspace that can then be accessed by developers using the “Tools” → “Maintain Libraries…” → “Add Library…” feature of the DataFlex Studio.
So I set about working out the best way to deliver source code as a usable minimal DataFlex library workspace without all the unnecessary overhead. Since it is Christmas, I thought I’d share.
We will begin with the assumption that you have already created the source files which you want to deliver in your library and have them available elsewhere on disk in some other workspace.
We start with the “New Workspace…” option from the Studio’s “File” menu. This fires up the “New Workspace Wizard”. On the second page, after giving it a name, description and directory, check the little box “Edit Workspace Paths” and click “Next”.
On the next two pages tab through each of the entries, replacing the last part of each of the defaults with “.” (yes, just a period), so that:
and so on.
Click through the rest of the Wizard until it finishes, then immediately exit from the Studio.
Having done that, open the workspace directory in Windows Explorer (or File Explorer, or whatever). You will see that there are still quite a few things in there:
Select the CodeMast.dat file, hold down the “shift” key and select the CodeType.tag file (thus selecting all the “Code*” files), then press “delete” and confirm you want to permanently delete these 10 items.
Now select FlexErrs.fd and again press “delete”, confirming that you want to permanently delete the file.
Do the same for each of:
That should leave you with something like:
This turns out to be almost the minimum you can get away with if you are not going to get errors when you open it in the Studio (and even then, there will be a little red warning message saying that the Studio is unable to open CodeMast in the “Output” pane), however as we will see, there may never be a need to open it directly in the Studio, so if you like you can go one step farther and also delete DDClassList.xml (the lack of which will not stop you opening the library in the Studio, but will give you an error).
Now using Windows Explorer, copy in the files you actually want to deliver in your library. I will use the RESTful services library I have recently been working on – there are just four class packages, a constants package and an include file, giving us:
If your library requires to add classes to the Studio’s Class Palette then you can also copy, from where you created it, the contents of the AppSrc “config” directory to the “config” directory of your Library workspace, overwriting the “classlist.xml” file already there.
Inevitably there will come times you need to make changes to your library: things you want to add; fixes for reported bugs; etc.
You can deal with this situation two ways.
- Instead of actually opening the library, you can instead open a workspace that uses the library and make your changes through that. This is often a good idea anyway: having a way to test any changes you make within a full application.
- Or you can open the library in the Studio, make your changes, then close it again. If you take this approach then after closing the library in the Studio (either by closing the Studio instance or by opening a different workspace with it) you will find that the Studio has recreated several files that you had previously got rid of:
To fix this you will once again have to manually delete the files:
This done, your library will once again be in the minimal form ready for delivering to the developers who want to use it. In this case (my REST Library) it is under 700 Kb in size or just 26 Kb when maximally zipped up.
A very Merry Christmas and a happy New Year to you all!
Addendum: Wil van Antwerpen (from Antwise Solutions) points out that while the library workspace does require to have a Filelist.cfg present, that file can be of zero size (i.e. the Studio does not check it for any expected content), thus you can save even more space (e.g. open it in an editor such as Notepad++, delete all content. then save it) . With this the total size of my REST library is reduced to less than 130 Kb (although this has no effect on its zipped size). Thanks, Wil!