Most Smalltalk projects, just like any other, consist of much, much more than simply the source code you write. There are icons, images, sounds, ini-files, xml files and many more. Some of these are text based, some are binary.
A modern project needs a mix of tools to edit all these file types. And, of course, if you (and you do) have to keep track of versions and configurations of your deliverables, you need to store them and keep track of changes in them.
Envy is a really powerful and cool tool for managing Smalltak code (in fact, it has proven to also be the same for Java in IBM’s VisualAge for Java), but it also is a bit different from many other version control and configuration management systems, in that it is not file based, but uses a far finer-grained model of classes and methods.
So it is very good in keeping versions of Smalltalk (or Java, or theoratically any class bases language’s) source code, but it falls a bit short in managing other artefacts.
In my talk at the VA Smalltak Forum 2010 (“Get your project back in shape – how a few techniques can change your (project’s) life“) I’ve discussed two options for using the envy library manager to store non-smalltalk artefacts.
One is the possibility to convert files into class or instance methods. There are, again, two possibilities: generating a method that simply returns a constant String with a file’s contents (similar to the way File Libraries in Seaside work), or generating a class model for a certain deliverable and methods that build a concrete instance of such an object, which in turn knows how to write itself to a file. The second option is more work, but offers a lot of advantages, like making tracking changes much easier and providing more flexibility. The biggest advantage is that you can use the full power of Envy to edit the underlying object structure of a file (like a DOM tree of an html or xml document or the stanza/line tree of an INI-File) in a team and keep track of all changes, and most importantly, lower the chance of conflicts between team members’ work. What I mean by this is that it is quite likely that even if two developers work on the same ini file, they probably change two separate stanzas.
This is, however, not the perfect solution for very complex or binary files. There’s not much use in trying to model an OpenOffice-Document or a JPEG image in a Smalltalk structure (well, there may be scenarios where there is, but most of the time not) just to make it manageable in the Envy Library Manager, and writing an editor for these formats makes even less sense.
For such cases, there is a second option: so-called user-defined fields. You can attach any kind of data stream to an object in Envy and store it in the library. The API for this is somewhat documented, and this way of storing information is very reliable and stable. If you ever wondered where all the layout information of a visual or non-visual part that you built in the Composition Editor is stored, let me tell you a secret: this is stored in user-defined fields. So you can use the library manager as storage for practically all kinds of data.
Just yesterday Marten came up with another open source tool he made that allows you to import external files into user-defined fields and store them in a library:
After years of being not satisfied how to handle external resources with my source code I decided to build a little goodie to get rid of this situation.
The MSKResourceManager will allow me to import binary data (e.g. files) into an application, where a special resource class is located.
You can also export the files to your file system again.
This is especially great if you want to export an application from your manager library and send it so somebody together with a bunch of external files. They’ll be in the same .dat file as your source code.
This also opens a few interesting options, like packing a documentation file into a goodie that you want to upload to VASTGoodies to share with other VA Smalltalk users. Or accompanying XML files or icons.
I am not sure if Marten had that in mind, but MSKResourceManagement is a very helpful tool for a problem we had with VASTGoodies: how do I ship a little documentation or a few files with my goodie? You can do so now by using user-defined fields without digging down into the depths of envy.
There are, however, a few things to take into consideration:
- the fact that a resource is stored in Envy as a user-defined field does not mean you have it under version control
- A Library currently can grow up to 16 GiB, so at least in theory there is quite some space for external resources in a library manager. I’ve never found any mention of a limit to the size of a user-defined field, but I guess there are better ways to store big files than in a library
- A user-defined field is just a (potentially big) pile of bytes so there’s not much support for doing anything with it other than importing and exporting it
Joachims Small World 