Move Assets/Content/Includes files to sandbox Data directory?

[vdhamer]

There are now 2 ways of using Ignite:

1. As a package that contains it own @Main entry point to make it executable. This happens when the code can find a Package.swift file somewhere in its path. This is what’s described in the README file.
2. As a package that you gets added to an existing app. See #119 and #126 that respecively cause the app to read the app’s sandbox Data directory (e.g. for image files) and write to the sandbox Data directory (to store the generated website).

Suggestion is to deprecate (1) and use the (2) approach in both cases.

Benefits

• Simplifies the source code. Currently the code uses (2) as a fallback if (1) cannot find Package.swift.
• The README file doesn’t need to describe both options or have user find option (2) in the code.
• (2) is more inline with how sandboxed MacOS apps are supposed (?) to work: read/write to an app-owned Data directory in app’s container directory /Users/username/Library/containers/appname/Data
• Adheres to classic distinction between files needed to build the app, and files needed to run the app. For a developer, building and running are two very different things.
• Allows an app that uses Ignite to be distributed and run by non-developers. This option makes sense when the app provides users a way to generate a unique site without updating/rebuilding the Swift code (input file, database, API, user input…). In other word, it (only) adds value if the lifecycle of a site layout and content are decoupled. Which the app developer’s choice.
• Simplifies the role of IgniteCLI to just running a local HTTP server and launching a browser session for localhost:8000. Creation, clearing, filling of directories is then done by the Ignite package (already partially the case).
• Most of the required changes are already in place in the current version. Just requires
  • minor package code simplification
  • update to documentation
  • IgniteCLI simplification?

Drawbacks

• Build output directory doesn’t show up in Xcode Project Explorer panel.
• Rebuilt existing apps that use (1) will find their output elsewhere in the file system. Worth a print() statement to specify the output path.

Discussion

Ignite tends to blur the distinction between code and data because you determine the visuals and the content of the website simultaneously: you code, build, review, edit code, rebuild, etc. But this doesn’t apply if you want your code to pull in data from external data sources: your typical workflow may involve running a build multiple times while editing something upstream (e.g. JSON file or database providing content of a List or Table or Cards or Images). In this usage, the Swift code determines the visual look-and-feel of the website and the data determines the for-eachable and regularly changing parts of the content.

Currently Ignite is positioned as generating fully static sites (e.g. change once a year, where both layout and content in principle change simultaneously).

This leaves generating dynamic stuff to on-the-fly frameworks like Vapor (e.g. daily content changes). Fine with me: that distinction is pretty fundamental.

This proposal is about the middle ground of regenerating whenever the content needs an update (e.g. weekly, monthly under end user control, without requiring developer skills) while the layout changes infrequently (as an app update).

[cpah]

I much prefer to stick with Option 1, because I do not want my Build folder to be written to the sandbox Data directory. Whenever I update my website, which is not infrequently (as is the case with most sites that host blogs, I would have thought) I upload it to my internet host via FTP (with FileZilla). I need easy access to my Build folder and prefer not to have to drill down to a Library/containers ... folder. I also need easy access as I test my website on an iPhone by airdropping the Build folder to my iPhone and opening it with the WorldWideWeb app. Please do not deprecate Option 1!

[vdhamer]

I need easy access to my Build folder and prefer not to have to drill down to a Library/containers ... folder. [..] Please do not deprecate Option 1!

First of all, the full paths of both locations typically have a comparable number of levels. You may experience it differently if you store your projects directly on the desktop. Secondly, MacOS has various options that can teleport you to any locations in a single click. See 3 ways to bookmark a folder.

A bit off topic, but I am intrigued about your airdropping of the Build folder to an iPhone for testing. I couldn’t get it to work on an iPad. Does it really give a workable directory with all the css/js bells and whistles, or are you only opening the index.html file in Safari? On MacOS you first need to start up an http server (courtesy of Python) to get a localhost.

[cpah]

I have more than one website so I have multiple Build folders. Each Build folder is a subfolder in its website folder, which is in turn a subfolder in my ignite folder. My ignite folder sits alongside other folders that I use for developing websites, e.g. hugo and middlemac, in my Sites directory. I’m not sure how Option 2 would support this situation.

The app that I use to view my websites on iOS and iPadOS is WorldWideWeb, which provides an http server. There is a macOS version for those who prefer to avoid the complications of using Python’s Apache server. WorldWideWeb is not free but it’s very affordable and I find it very good.

[vdhamer]

My ignite folder sits alongside other folders that I use for developing websites, e.g. [..], in my Sites directory. I’m not sure how Option 2 would support this situation.

Your folders for both Source (inc tools in this case) and Dest (at least the .app file) already exist on your Mac and are already at different locations. In /Users/username/Library/containers/ (Dest) you will find subdirectories for each MacOS app you are developing, as well as for binary-only apps such as Pages, Mail, whatever. So your development projects would reside in the existing /Users/Chris/Library/containers/MyApp1/Data (Source) directory. And just get a subdirectory Build for holding files the app needs at runtime or generates at runtime. As far as I know (I am more into iOS dev) this is “normal” for MacOS apps. After all, Apple or 3rd party apps don’t come with source code or require recompilation by the end user.

The Source code stays where it is now (myPath/Ignite/MyApp1) and would still contain a subdirectory from which resources (.bmp, .jpg, .js, .css, .md, etc.) destined for /Users/Chris/Library/containers/MyApp1/Data are automatically copied. That copying from the Source environment to a separate Dest environment is already supported in the current version of Ignite.

So the only difference is where to find the Dest environment from which you ftp to a server or Airdrop to a device. Right now the code supports two options. Each of which is tricky to explain clearly. Possibly because option 1 is a bit of an hack? And explaining both is trickier (the README file for Ignite is not yet up to date on this point).

In any case, I won’t submit a Pull Request until we hear where @twostraws wants to go. He values clean code and (especially) simple explanations/documentation. My own problem is solved (it now works), but the solution is insufficiently documented. Just updating the documentation for the current state will make usage instructions a bit more complex. Hence my proposal…

[cpah]

Thanks for a very detailed comment. However, I cannot find any trace of my ignite websites in my Mac's User/Library/Containers directory. On the other hand, I can find folders for the macOS apps (rather than packages) that I have developed with Xcode and run locally. This is as you state and as I would expect; I have a macOS app on the Mac App Store (MyNetWorth), which routinely accesses a file that resides within its container. However and as I understand it, when I run an ignite package in Xcode, it does not build and run an ignite app; it simply compiles its contents and populates its Build folder, which already exists, having been created by the ignite new Site command. As a result no Container entry is generated, I believe, because no new app is created or run. On the other hand, if you include the ignite package within an app project and compile / run that app project locally, I presume that a Container entry is generated as normal and this entry will, I guess but I don't know, include an ignite generated Build folder. I'm glad to hear that your own problem is solved. However and having not had a problem so far, I still believe that I will need (Option 1) access to Build folders that are generated and reside in my websites' Source folders.