Closed rmortes closed 1 month ago
If it helps, here's the outerHTML code generated by each of those examples
Okay, let me see. Default values is something that is not fully resolved in the CMS.
I've released the version 0.6.0:
mode
option for date
and datetime
fields was removed. It wasn't a good design decision.current_datetime
field that you can use to update automatically the document with the current date when it's saved.value
option now works fine and it's used as the default value for new documents.DAMN that was fast O.o I'll check it out ASAP and let you know if it works correctly
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
You're right, the current_datetime
field generates the value when the form is loaded, because the following reasons:
But you have some valid points too. So maybe the behavior can be improved. Some ideas:
What do you think?
If you like the idea and want to work on that, it's just editing the web component file.
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:
Additionally, I've added a new component, readonly_current_datetime, that behaves how I personally think it should:
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?
v0.6.1 released with fixes in current-datetime
.
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
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!