Extract templates to files for development

[vokal-isaac]

A working (as in produces identical output on all four sample projects) version of Cat2Cat where, for development, the templates are individual .mustache files that can be edited easily (rather than string constants in code). At build time, the templates directory is zipped and the zip file is embedded (by the linker) into the Cat2Cat executable. At runtime, Cat2Cat loads the embedded zip data and uses the template files contained in it to render the output.

@vokal/ios-developers Code review please?

[designatednerd]

Oh, this oughta be good.

[designatednerd]

What's the advantage of using mkdtemp instead of just using the NSFileManager to create a directory which you then delete later?

[vokal-isaac]

From http://www.cocoawithlove.com/2009/07/temporary-files-and-folders-in-cocoa.html (and I've added that URL in the docu-comment above this function):

To avoid concurrency issues (race conditions), you need to choose a name for any file or directory placed directly in the temporary directory that is unique but which also can't be stolen by another process between choosing the name and creating/opening the file or directory. Even though NSTemporaryDirectory() is unique for each user, you still must avoid potential conflicts within the user's account.

To do this, we use the POSIX function mkstemp for files and mkdtemp for directories. The former will return an already open file descriptor for the file and the latter will have already created the directory for us.

Note that this is much less of a thing on iOS because of sandboxing—for a given iOS app, the filesystem the app sees pretty much belongs entirely and solely to the app, so there's much less concern about what a malicious app sharing the filesystem might be able to do.

[vokal-isaac]

Don't merge this. I've been doing some more thinking and poking around and I might have a better solution that doesn't need the temporary directory at all and, instead, makes use of the zip archive straight from memory.

[vokal-isaac]

I've rewritten this so that:

• the templates are read straight from the loaded zip data without having to write them to the file system and clean up later, which removes the need for a temporary directory
• the code to create a ZZArchive from a zip file that's been embedded in the Mach-O executable by the linker is encapsulated in a category on ZZArchive
• the mechanism for having a GRMustache template repository based on a ZZArchive containing the templates is encapsulated in VOKZZArchiveTemplateRepository

I'd kind of like to expose those two encapsulations as optional subspecs of the Cat2Cat cocoapod so that other utilities can use them, but that can wait for later (or maybe they should be their own cocoapods).

[designatednerd]

Per your comments, is this still being extracted to a temp directory?

[vokal-isaac]

D'oh.

[designatednerd]

I like this strategy. I would definitely vote separate pod rather than making them subspecs of this utility, though - they're something that helps this be more efficient, but it's not super duper related to Cat2Cat itself.

Let me know if you want me to make you a repo for that.

[vokal-isaac]

Yes, please. Maybe something like VOKEmbeddedTemplateTools?

[designatednerd]

Done! I added you as a maintainer on that one.

[designatednerd]

( 🐐 , 🐐 , 🐐 )

[designatednerd]

@vokal-isaac This doesn't need a version tag or a pod trunk push yet, correct?

[vokal-isaac]

Correct. At a minimum, I'd want to do the split out of the new pod, but even then I'm not sure it makes sense to push a new version, as this produces identical output and changes nothing from the consumer standpoint. It's really a dev side improvement.

[designatednerd]

👍 thanks!