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:
1 | Dear developer, //Well, that's already a good start on any conversation! :) |
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:
- Name
prj_start_date
; LabelStart date
; TypeDate
- Name
prj_start_hour
; LabelStart hour
; TypeInteger
; Default value will be12
; Minimal value0
; Max. value23
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:
- Remove the
Start date/time
from the create screen and only show it in your lists or “readonly” forms. - Make the
prj_start_hour
a static Enum; This way you have a dropdown to select the hour. - Have a second look on this expression (which introduces a lazier loading approach in your form; and works!):
1 | 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”?