Default values not working

[rmortes]

I'm trying out Lume. I'm liking it so far, but I found a small problem. Default field values aren't working

Version

"lume/": "https://deno.land/x/lume@v2.2.3/" "lume/cms/": "https://cdn.jsdelivr.net/gh/lumeland/cms@0.5.5/"

None of the following configs make a default value appear on the frontend

{
  name: "date",
  type: "datetime",
  label: "Published date",
  value: new Date(),
  description: "Set a future date if you want to publish it later",
  attributes: {
    placeholder: "For example: 2024-01-01 00:00:01",
  },
},

{
  name: "content",
  type: "markdown",
  label: "Page content",
  value: "Write **markdown** code here",
  description:
    `<a target="_blank" href="https://www.markdownguide.org">More info about markdown syntax</a>`,
},

{
  name: "createdAt",
  type: "datetime",
  mode: "create",
},
{
  name: "updatedAt",
  type: "datetime",
  mode: "update",
},

If it changes anything, I'm trying to use DenoKV to store my data, but I've also tried with the disk driver and it's the same behavior. Am I doing something wrong here? Thanks!

[rmortes]

If it helps, here's the outerHTML code generated by each of those examples

Example 1

```html Published date

Set a future date if you want to publish it later

```

Example 2

```html Page content

More info about markdown syntax

```

Example 3

```html Created At Updated At ```

[oscarotero]

Okay, let me see. Default values is something that is not fully resolved in the CMS.

[oscarotero]

I've released the version 0.6.0:

• The mode option for date and datetime fields was removed. It wasn't a good design decision.
• There's the new current_datetime field that you can use to update automatically the document with the current date when it's saved.
• The value option now works fine and it's used as the default value for new documents.

[rmortes]

DAMN that was fast O.o I'll check it out ASAP and let you know if it works correctly

[rmortes]

Already tested. It's almost working perfectly now. I can set the createdAt value correctly, and the updatedAt is stored correctly as well, but not displays the correct information. Let me elaborate. I'm using the following setup:

{
  name: "createdAt",
  type: "datetime",
  attributes: {
    "readonly": true,
  },
  init(field) {
    field.value = new Date();
  },
},
{
  name: "updatedAt",
  type: "current_datetime",
  attributes: {
    "readonly": true,
  },
},

I can create a new document, and edit it as well, and the database will always contain the correct createdAt value and the correct updatedAt value. However, the UI will display the updatedAt value as the current datetime, regardless of the database value. I understand why this happens, I think. To keep the updatedAt value up to date, you just change the value in the form to whatever the current datetime is, so that when you save the form, the value gets updated as well.

However, if a less tech-savvy client sees this, they'll be pretty confused about why this is happening.

I think the solution would be to display the database value in the form, but to send the current datetime whenever the form is updated.

This can get rid of another edge case I just noticed. Since you set the updatedAt value to the current datetime when the page is loaded, if I take my time editing the collection and save it, the updatedAt value will not be correct, it'll be however minutes it took me to make the edit earlier than it should.

I don't know if currently your implementation allows for this. If you don't have the time required to make this changes, maybe I can chime in and lend a hand? I'll probably end up contributing to the repo either way since I hope to start using this CMS in production pretty soon

[oscarotero]

You're right, the current_datetime field generates the value when the form is loaded, because the following reasons:

• If the previous value is shown, users may think this value is not updated automatically.
• Sometimes, the user want set a different value because reasons.
• It would be confusing to send the form with a value, and a different value is stored.

But you have some valid points too. So maybe the behavior can be improved. Some ideas:

• The input shows the current time (as it does now).
• But every minute (or second), the value is updated (like a clock)
• If the value is changed by the user, it's not longer updated automatically.
• Maybe, we can show somewhere the previous value, just in case the user want to keep the previous value.

What do you think?

If you like the idea and want to work on that, it's just editing the web component file.

[rmortes]

I've opened a pull request for this issue (https://github.com/lumeland/cms/pull/23)

I've changed the current_datetime component to behave the way you suggested:

• The previous value is shown below the input (the wording is terrible, I'm a backend dev what can I say?)
• The value is updated automatically (each second) to reflect the current datetime
• The value stops updating once the field gets "dirty" (the user updates it manually)

Additionally, I've added a new component, readonly_current_datetime, that behaves how I personally think it should:

• The field is readonly to let the user know they are not supposed to change it in any way
• The value corresponds to the last time the collection was modified
• The value is updated just before the form is sent, so it changes locally for the user (they can see the collection was updated "just now") and the new value is sent with the form so the database value changes as well

Honestly, the name "readonly_current_datetime" seems terrible to me. I'm thinking "updated_datedate" or "updated_at_datetime" would be better, since this is a pretty opinionated field and the name reflects that. Wdyt?

[oscarotero]

v0.6.1 released with fixes in current-datetime.