Prepare for the dynamic aspects of the site

[cdchapman]

Or we need some way to build and compartmentalize both the static and dynamic aspects of the site to prepare the way for the dynamic aspects of the site (issue #14).

Here is what I envision as possible dynamic aspects of this site:

• Social Web functionality, such as WebMention (issue Add WebMention functionality #22) and increased diversity of outputs (issue Add the ability to post different types of things, such as notes, publications(?), in addition to blog posts. #44)
• Commenting (possibly: this need may be filled through hypothesis)
• Some sort of interaction that eased collaboration in developing ontologies
• A sandbox for research cases and other collaborative interactions that have to do with research
• Future integrations with backend systems, where dynamic aspects would be better than simple proxying
• …

My question is really: how do we separate the static content and the server configuration files (which we don't want to serve) when we build them together? Or is there a way to build them separately?

On some level, I don't think we will need the dynamic server functionality for most content development, but then again, why have an arbitrary separation or complex, variable process when we don't have to? Either way an HTTP server is running; this issue is only about how to dynamically change the server and the server configuration. Issue #33 is related to this.

Here are a few requirements:

• There should as no difference in functionality between environments (i.e. all commands should work and do essentially the same thing)
• It should still be possible to run nanoc view and functionally view the static site
• It should be possible to use a static_only environment to build the static stuff only
• Server configuration should not output in a way that they could be served via HTTP
• Have the ability to use environments to set different output paths for content and server configurationactually this is not needed for development or deployment, as I thought it might

I like the approach below. Here is what would need to be done to implement it:

• Move the items directory to content
• Adjust nanoc.yaml accordingly
• Update site rules to deal with these new item identifiers
• Use site config and rules to dynamically set the root of the outputted item paths (see comment below)
• Patch the nanoc view command that takes the configuration for the static root into account
• Patch link_to to remove the /static/ root for link generation
• Update sitemap and blog feed (see issue Redesign ATOM-feed helper #21) helpers to use the public_path_to helper
• Add a static_only environment that ignores all of the server items during the build (see another comment below)

Would be nice to do to know that this setup actually works:

• Add the server|app datasourcemove everything back to a consolidated datasource (see comment below)
• Merge in existing nginx config repo
• Setup openresty project
• Resolve issue Create nanoc command for the server #33 by implementing a nanoc server command

[cdchapman]

Having separate environments for content and server configs may be one way to handle this

For example:

.
└─ output
   └─ app
      ├─ app.lua
      ├─ content # ← into this folder would the static files be built
      └─ …

To do this, we could either arrange the files in the items directory in such a pattern, or what might be better would be to use two filesystem datastores: one for the static content, and one for the server configuration.

.
├─ content
│  ├─ assets
│  ⋮
│  └─ specifications.erb
└─ server
   ├─ app.moon
   ├─ nginx.conf
   └─ views

and use a different items_root for the content filesystem. Going back to placing the static items in the content directory may also be a little more conventional for a nanoc build.

[cdchapman]

The more I think about this, I'm wondering whether it would be best to simply use one filesystem datasource, and use this for both the static and dynamic parts, arranging it in a unified way. I think this would give a structure that was more consistent, expected, and simple.

Such an approach could look like this:

.
└─ items
   ├─ app.moon
   ├─ nginx.conf
   ├─ static
   │  ├─ assets
   │  ├─ blog
   │  │  └─ index.erb
   │  ⋮
   │  ├─ specifications.erb
   │  └─ videos
   └─ views

So the content_dir and the output_dir would have an analogous structure. This would also give us the flexibility to decide which items should be generated statically and which would work better as dynamic.

[cdchapman]

I don't see the reason anymore to have the static_only environment, unless it is to avoid filters that require lua or other dependencies. So keep the environment for now, but if we find it is not useful, get rid of it in the future.

[cdchapman]

I want to revisit storing the static root under the dynamic items. It makes most of the paths when editing one level deeper. Beyond that it seems like we're dealing with two different logics here, and that a separation would be useful as we move forward.