|
export.importFolderA few days ago I fixed an old useful script-verb that was broken in the transition to Frontier 5, export.importFolder.If you're part of the Root Updates process, as we move towards 5.0.1, you already have the new version of export.importFolder. Why export.importFolder? For small things, like a simple verb or a suite, or even a moderate sized website, a single fat page is a very sensible way to go. It may use a lot of memory to load it in (that's getting better in 5.0.1, by the way) but it's easy, both for the publisher and for the user. But some things are so large that they can't be installed thru this mechanism. For example, I want to release the full source to the Scripting News website, but if I released it as a single fat page, it would require 20MB of RAM (maybe more) to read it. So we solved the problem another way, with export.importFolder. How to install
Changes It needed an update to work with Frontier 5. It was strictly Mac-only, couldn't read fat pages files, and had calls to verbs that were moved in version 5. Further, there was a flaw in its design. The design flaw: It was relying on the folder names to build the structure of tables, but there are limits on folder names that don't apply to table names, so you couldn't fully represent an odb structure if we depended on the folder names. Luckily the full address of the object is stored in the fat pages format, so the new version of export.importFolder just reads every file in and imports it. It's a verb You can call it from the Quick Script window, or from an installer script, or from a menu item or an agent, where ever it makes sense. It takes one parameter, the folder you want to import. The other side export.sendFolder creates folders that can be read by export.importFolder. It's included in the latest root update. Please use this verb to create folders to be imported by export.importFolder.
|
|||||||
|
||||||||