Add tags to Yancy schema

[wbazant]

Also datetime -> date, which the UI renders as a nice calendar

Needs preaction/Yancy#72

[coveralls]

Coverage remained the same at 86.182% when pulling ab807f1 on wbazant:v2 into 24f6c25 on preaction:v2.

[preaction]

Excellent! Thanks!

We'll have to make the data section work somehow once the editor has support for it (or has a way to ignore fields that it doesn't understand...) A lot of the extensibility and magic comes from that arbitrary hash.

[wbazant]

@preaction What do you think the data section should contain - the same as in statocles.conf?

If that, I'm not sure if per-post data are good, or for that matter, theme or layout - I don't think it's common for different posts in a blog to have different layouts or a custom nav bar.

[wbazant]

Can you also merge the dependency preaction/Yancy#72 - (Yancy editor learning how to show the array tags in the UI)? I guess you've tested both together.

[preaction]

The editor enhancements are now merged.

The per-page data hashref goes together with the template/layout settings to do interesting things: Since the data is available to the template, I could have a recipe template for certain posts that uses schema.org metadata built from the data in the data section. Or, with the magic index page feature, I could create entire applications (an advent calendar perhaps) using only different templates. I used the data section to create a gallery of Statocles sites.

This also replaces the v0 feature of content templates: I'm no longer allowing Mojolicious template directives in all the Markdown files, so one way to still get some of that functionality is to use custom templates along with the data section.

[wbazant]

@preaction If I see the vision now: to make a Statocles-powered recipe blog, a blogger would create a custom post template that renders properties they want, ideally picking them from https://schema.org/Recipe: maybe a little clock that shows cooking times. Then, to each post they would add to the frontmatter

data:
  cookTime: 30 minutes

or, even better, add it through the Yancy UI.

I've had a look at supporting objects, there's a bit to it: the keys are defined via properties field, the recursion on values can work like for arrays, new key-value pairs added based on additionalProperties. I can have a go.

It would be pretty good for Statocles to have capacity to support different kinds of sites through initial setup - a particular format of posts, a template, maybe a config. Except with the configs, like you said in #586 there's also a pull in the opposite direction of not making the configs too complicated.

What do you think about making the schema flexible? Possibly this could also involve inheriting from a base that would have properties that mean something to the code: template, layout, path, etc. The advent site would have author and date, a neat collection of recipes would have cookTime and ingredients etc.

[preaction]

Yes, basically. Some of the most popular modern static site frameworks are built largely in JavaScript modules: GatsbyJS (React), Next.JS (React), Nuxt.JS (Vue). This is kind of the same thing, but one uses Perl.

With the way Yancy::Backend::Static works, you can add whatever additional fields you want. The read_schema => 1 will combine the properties from the backend with whatever you add. Yes, that functionality will be made available in the Statocles config. Having a config that is possible to become complicated is okay as long as it's not required to be complicated (so, there's a default for anything complicated that is generally what the user expects).

There's a lot of ways to go with some of these things, so it's probably better to let some of them grow naturally while solving real-world issues. What we've talked about so far is stuff that is being used in v0 Statocles sites in the wild, so it's definitely going in eventually.

I do like the idea of being able to generate different kinds of sites/pages from a "template". We could create some command that could do it, even perhaps using a Mojolicious template to create the initial Markdown from some kind of configuration (so, a command generates the Markdown, and then Statocles generates HTML from that Markdown... inception!) It's my hope that the v2 branch makes things like this easier, because v0 was definitely not going to be able to do it 😛

I would probably be against any kind of "Setup wizard" or required initial setup command. The v0 has that, and it might be helpful, but it's hard to test and maintain, and ended up just kind of making things harder: It's a barrier to getting going, and it's not the right time to start telling folks why all these questions matter. But also, a "Setup wizard" says that a website will never change over time, which is incorrect. Better to have commands that can generate sections of a site for specific purposes at any time.

[wbazant]

I share your negative stance towards setup wizards. For initial setup, I imagine a programmer's method of taking the initial structure, overriding the defaults until they're different enough, and then mostly just keeping going.

Taking your recipes site as an example, you'll probably create a new template, configure the navbar through the config, etc. and when you add new recipes you mostly won't revisit this setup. Similarly, you could decide all your recipes should indicate a "cookTime" and "ingredients", and prepare a schema that will guide you in this. To then add a new recipe, you would open the Yancy UI, which will remind you to provide cook time and list the ingredients.

I think the best way to support this kind of workflow is by letting things be changed, and documenting what gets configured where, maybe through a wiki, together with an inspiring default setup.

On generating everything: v0 has a workflow to create a new post, and it could stay in v2 as a command line version of "Create new item" in Yancy, but I'm not quite seeing the benefits of templating the post body itself.

[preaction]

True, creating templates to generate markdown for editing is probably a bit useless (it's that kind of boilerplate that I'd rather seek to avoid by setting a template for the page instead of finding ways to make a bigger mess).