Supplying default values for fields

[Gordon Fontenot]

I just spent a bit trying to figure out how to supply a default value for a
field and didn't get very far before I felt inclined to duplicate a bunch of
lib code. This seems like something that might be useful in general, but
here's my specific use case:

I'd like to tell Hakyll to display posts in my 'drafts' folder when running
the `watch` command. However, I _don't_ want to add explicit dates to those
drafts. So I'd like to tell Hakyll that it should use today's date if it's
unable to parse a date from the file using `dateField`.

This seems really difficult to do with the current system. Am I missing
something? Is there an existing way to do this? Is this something that I
should open an issue for on the repo?

[Daniel Gnoutcheff]

On 08/01/2017 08:04 PM, Gordon Fontenot wrote:
> I'd like to tell Hakyll to display posts in my 'drafts' folder when
> running the `watch` command. However, I _don't_ want to add explicit
> dates to those drafts. So I'd like to tell Hakyll that it should use
> today's date if it's unable to parse a date from the file using
> `dateField`.

Perhaps something like this would do:

let ctx = dateField "date" "%F" `mappend`
modificationTimeField "date" "%F" `mappend`
defaultContext
pandocCompiler >>= loadAndApplyTemplate ctx "template/..."

When this context is asked to produce a "date" value, it will try
dateField first, and if that fails, it should fall through to
modificationTimeField, which uses the last-modified date on the
underlying file.

Alternatively, we could replace `modificationTimeField` with any other
context that includes a "date" field, such as

constField "date" "January 1st, 1970"

If we *really* wanted "today's date", we could construct a `buildDate`
field using `field`, `unsafeCompiler`, `getCurrentTime`, and `formatTime
(the latter two from `Data.Time`). But I suspect that one of
modificationTimeField or constField would be close enough. :)

HTH,
Daniel

[pbri...@gmail.com]

[Gordon Fontenot]

That isn't working for me the way you're describing. I'm not sure if it's
something specific to the internals of `dateField`, but I'm still getting an
error from `getItemUTC`:

```haskell
postCtx :: Context String
postCtx = mconcat
[ dateField "date" "%b %d, %Y"
, constField "date" "January 1st, 1970"
, defaultContext
]
```

Results in:

```
❯ stack exec site build
Initialising...
Creating store...
Creating provider...
Running rules...
Checking for out-of-date items
Compiling
updated templates/default.html
updated partials/head.html
updated partials/header.html
updated partials/footer.html
updated 404.markdown
[ERROR] Hakyll.Web.Template.Context.getItemUTC: could not parse time for drafts/test-draft.markdown
```

[Daniel Gnoutcheff]

On 08/04/2017 04:28 PM, Gordon Fontenot wrote:
> ❯ stack exec site build
> Initialising...
> Creating store...
> Creating provider...
> Running rules...
> Checking for out-of-date items
> Compiling
> updated templates/default.html
> updated partials/head.html
> updated partials/header.html
> updated partials/footer.html
> updated 404.markdown
> [ERROR] Hakyll.Web.Template.Context.getItemUTC: could not parse time
> for drafts/test-draft.markdown
> ```

Hmm, this might not be a templates problem after all. I don't believe
this error message would arise from our use of dateField; it more likely
came from something else that uses getItemUTC. Possible culprits
include chronological, recentFirst, sortChronological, and
sortRecentFirst (all from Hakyll.Web.Template.List). Are we using any
of those?

Unfortunately, all four of those functions are hard-coded around
getItemUTC, and I believe they will die if getItemUTC can't extract
dates from all of the supplied items. If that is indeed the case, we'll
need to work around that somehow.

[Gordon Fontenot]

> It more likely came from something else that uses getItemUTC. Possible

> culprits include chronological, recentFirst, sortChronological, and
> sortRecentFirst (all from Hakyll.Web.Template.List). Are we using any of
> those?

Aha! Yes, that's it exactly. I'm using `recentFirst` after loading my
snapshots.

This might be fine for now though. I feel like this should be easier for me to
work around than what I thought was going on. I'm happy to know that I was
just Holding it Wrong.