How Field treats files

Field stores your work in .field files.

In casually using Field you might have noticed a few strange things about these files. This page collects information about these files and how you can use them, share them and archive them.

.field files are actually directories

First of all .field are actually directories. This is fairly common on OS X; the Finder participates in a conspiracy to hide this fact from you, but you can always right-click on the field file and "Show Package Contents". Why should you care? As soon as you want to send a field file to someone in an email or in an instant message you'll discover that it doesn't work. The simplest solution is to turn it into a .zip file with another right-click "Compress".

field files want to live in the workspace

At the time of first launch Field asks you to select a workspace. This is the place that Field wants to put all of the field files that it creates. Field will complain if you open a field file from somewhere else:

fieldpackage files are useful for exchanging ideas

While you can pass around .zip'ed field files, sometimes you only want to share a box of code or two. And quickly. Don't miss the fieldpackage option described [PaletteOverview#Thegear-buttonmenu here]. Unlike field, it's a real file not a fake directory; it's also a subset of a sheet, not the whole thing. Great for IM, an email or a webpage.

The workspace is version controlled

Why is Field so determined to get files in one directory? So it can version control them. This serves two purposes. Firstly so that Field can offer up information about the history of a field file to you. Secondly this acts as a backup of sorts. You can always roll back to an earlier version (and the roll forward again) using that history viewer.

If you are familiar with [www.selenic.com/mercurial/ Mercurial], the version control software that Field uses, you can issue Mercurial commands directly inside the Field workspace.

The workspace can be a good place to put other data files

self.dataFolder is a property that is always points to a folder inside the workspace called 'data'. It's a fine place to put data files. (And if you are familiar with Mercurial you can elect to add them to the repository as well).

self.sheetDataFolder is a 'data' folder inside the field 'package'. A good place to put something that really needs to travel with the field bundle.

py files get some attention as well

Field tells OS X that it knows how to edit .py files. This is almost true — it knows how to automatically import a .py file into a brand new blank sheet and then let you edit (and run, and add other boxes and so on) the file there. You'll find buttons for syncing changes to the box that contains 'the file' back out to that file. Associations between .py files out in the filesystem and their sheets are maintained, so if you double-click on a .py again, you'll get taken back to the same sheet.