Hi Stef, It is quite simple really. (It had to be for me to figure it out.) First a class of the specified name is constructed. Then the files are read in, compressed with gzip and encoded into base-64 strings. Then a class method is created for each file that answers that string. The class method is named with a base-36 encoding of the file path in order to ensure a valid method name. A dictionary of the base36-encoded method names keyed by the file path is created and that is serialized with ReferenceStream, compressed, and base-64-encoded as well. A class method called #fileList is created that reverses the process to re-create the original dictionary. To restore a file, it is looked up in the fileList dictionary by its path and then the corresponding method is invoked to obtain the encoded content. The content is then decoded, uncompressed, and written to the file path. There are a number of class methods copied from TFFiler into the file container class that is created for such things as adding, removing, replacing, displaying, and listing the file container's contents as well as redirecting the file restoring to alternate destination. The created file container class contains a class comment that lists the contents of the file container. It is updated as necessary when files are added or removed. (I was actually glad to see FileSystem delayed, as I made heavy use of FileDirectory in TFFiler.) Best regards, TF On Fri, Feb 4, 2011 at 11:12 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Argh I want that! Now tony tell us what is the principle. I was thinking to add a git entry to a squeaksource but how do you manage them? Stef
I've published a tool I'm using called TFFiler.
My problem was that I had a number of external files that were required for my Seaside web application. These were CSS, Javascript, and image files that had to be placed in a specific directory tree structure. When I moved my web app to another system, I always had to remember to reconstruct the external directory tree. Over time, the directory tree got larger and more complex.
For deployment, I wanted the files to be served by Apache and not the Seaside ExternalFileLibrary. (ExternalFileLibrary was the most convenient approach during development.) This meant the directory tree should be moved to a location other than the Pharo Resources directory, which was the most convenient location during development.
The current version of Monticello does not provide a way to save external files with a project. TFFiler addresses this shortcoming. Now when I load my project from Monticello the necessary external files are deployed automatically.
Maybe someone else will find this useful as well.
http://www.tonyfleig.com/smallthoughts/blog/tffiler http://www.squeaksource.com/TFFiler
Regards, TF