/ Development  

You won't believe this simple trick for setting your date/time field default to 12PM

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

There he/she is again…The analyst guy/gal; Dropping by at your desk 😔. From experience, you know you’re asked to make the impossible, possible…So, let him/her just explain that one feature your end-users would love to have available into your crafted solution:

Dear developer, //Well, that's already a good start on any conversation! :)

The end-users are complaining they would like to have a date field which by default
sets the time at noon 12.00 PM. In 'special circumstances' it should still be able
to select a time yourself. Would this be possible for you to built?

Your sincerely and partner in crime,
"The Analyzer" ;)

O-boy…There we go again! You as developer already feel the pain as you know that a simple date/time field is not that manipulative in this scenario. We can off-course create an onChange ‘Rule’ BB triggering a BPM and manipulate data, but it will always “feel” a bit cumbersome because a date/time field requires the selection of a time which we need to reset afterwards. Can we make this smarter? Yes, my friend…we can!

Let get right into it…

Dive into your favorite AppWorks URL with the credentials for your Developer account. We start with a simple ‘Project’ entity and just one easy to create date/time property with the fancy name: prj_start_date_time. Make sure all the default BBs (incl. the entity display name) are in place and do a first publication into runtime to see a result like this:


I played a bit with the CSS function rgba(255, 255, 255, 0.8) to make it “glassy”; Now you see more what happens in the background! I also see some Dutch details (a browser thing?) passing by, but you get the point of the data/time selection! 🤠

Well, how on earth do we default the time here to 12.00 PM (Noon)? Yes, not directly! Let’s have a look at an interesting (non-BPM) workaround to make it happen…

It’s time to add 2 new properties…WHAT? Yes, the trick here is to separate ‘time’ from the ‘date’! So, create 2 new properties with this input:

  1. Name prj_start_date; Label Start date; Type Date
  2. Name prj_start_hour; Label Start hour; Type Integer; Default value will be 12; Minimal value 0; Max. value 23

So, this is your end-result:


Now, open the ‘Create’ form and update it like this (where you make the Start hour a required field):


Next step is to create a new ‘Rule’ BB…I give it the name e_on_propchange_set_prj_start_date_time and make it as simple as this:


Do a first publication and check the result of the Start date/time field after you select a value for field Start date! Do you see the magic? It gets copies with a default time of 00.00:


NICEEEE…Now what? Well, how about updating our ‘Rule’ BB like this: item.Properties.prj_start_date + 12 hours or even better; Like this: item.Properties.prj_start_date + ((integer)item.Properties.prj_start_hour) hours!? Try it out and see what magic we’ve just exposed:


The wonderful thing here is that it updates on each change! And that’s it for the great magic trick…

Just some thoughts for further improving, but I leave that specific task up to you:

  1. Remove the Start date/time from the create screen and only show it in your lists or “readonly” forms.
  2. Make the prj_start_hour a static Enum; This way you have a dropdown to select the hour.
  3. Have a second look on this expression (which introduces a lazier loading approach in your form; and works!):
date(item.Properties.prj_start_date.getYear(), item.Properties.prj_start_date.getMonth()+1, item.Properties.prj_start_date.getDayOfWeek()) + ((integer)item.Properties.prj_start_hour) hours

Don’t shoot the messenger on the getMonth()+1; This is what you find in the low-code guide (in the ‘Using expressions’ section)!?!?:


Ohww man…That’s a nice solution! Be proud of myself and a partner in crime that initialized this way of thinking (you know who you are)! 😁 “DONE”. Again, an interesting workaround with a simple ‘Rule’ BB and some helping properties on the entity which makes your end-users (incl. you analyst guy/gal) happy again. Pick the fruits on this knowledge and share it with others. I see you next week on a new AppWorks Tips topic.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?