Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
How did I get to this post? Well, last week I was wondering why my unconditional on_change ‘Rule’ BB triggers directly? This means “something” is already changing in the background; What is this “something”? How can we get more insight? And how can we use it in our advantage?
Let get right into it…
Spin up your machine, login with that precious dev-account, and dive into your workspace. I have an ‘entities’ folder available where we start creating a new ‘Project’ entity with just one property prj_name. Generate all the default BBs and make it nice and cozy. After publication, you can create a new instance in runtime.
While creating this new instance, make sure you have the Chrome developer console <F12> open in a side panel. Now watch and investigate the create-action from the network traffic tab and making the response readable with the format option in the bottom:
Aha…The platform exposes its hidden secrets! Time to update our ‘Create’ form and add some ‘Identity’ properties. This way we don’t need to watch the developer console but get direct feedback in the UI. Just like this:
After publication, and again creating an instance, we have our insight:
Continue creating the instance and opening it with the view layout we see a difference passing by:
What can we do with this knowledge? Well, how about a conditional ‘Rule’ BB checking if the ItemStatus == 0. This way the rule only fires on entity initialization and not when viewing it afterwards! Try it out yourself with a new event-type of rule with name e_on_propchange_message looking like this:
This almost “smells” like an
e_on_init_messagerule, but the ‘onInit’ event only fires once where the ‘propChange’ event fires at…Yes, at every property change…Duh! 🤣. On the other hand; You can get close enough to the only-‘Init’ feature by adding an extra condition to the rule…Try it like this and compare it with a real ‘onInit’ rule. Make your own conclusion…It all depends!
The ‘Cancellable’ form
The previous section covered a ‘Regular’ form, but what about the ‘Cancellable’ form? What is it and how can we use it into our advantage with the previous conclusions? All valid questions…Let’s continue the grind! Create a new form on our entity…This time of type ‘Cancellable’ with name ModalUpdate. Make the look & feel equal to the ‘Create’ form including the ‘Identity’ properties.
I though being smart inserting the ‘Create’ form as component on the form, but this is not possible for some reason…It’s grayed out!? I guess it’s the type of form which is not compatible with both of them.
Now we make sure to call this form from a new action-type of ‘Rule’ BB. Name it a_modal_update with label ModalUpdate. The configuration looks like this:
Publish the entity, open an existing entity instance in runtime, and hit the action button for an interesting exploration:
At this moment I’m very curious what is happening on the database side of things with the model popup still open!? Well, let’s query along with HeidiSQL:
select * from o2aw_tipsgenericproject:
You see that the ‘id’ already moved to
24. That’s because I cancelled the modal form a couple of times, and I see the ID increasing every time. After the ‘cancel’ or the final ‘save’, the entry is gone from the table! I tried to find out what encryption is used for thes_temporary_copy_data-part, but I leave it with you. During my research I found an interesting “CyberChef” website to encrypt/decrypt data.
Again the question: What can we do with this knowledge? Well, how about a conditional ‘Rule’ BB checking if the IsTemporaryCopy == true. This way the rule only fires in the modal popup. Just a condition like this on the previous ‘Rule’ BB:
NICE…Works as expected!
Busting a myth: “A property condition in a Rule BB will only work when that property is available on the form itself (visible or hidden)”. Well, I just tried it out by removing all three properties from the ‘ModalUpdate’ form and the rule still applies!
Answer to my initial question
Yes, what was the question? Why does my unconditional on_change ‘Rule’ BB triggers directly on form load? Well, my friends…It’s again a #RTFM topic, but let me give you a hint:
That’s the beauty of ‘Information’ icons…You start to see them once &^%&^% hits the fan! 😣
A quick, but interesting post this week! I give it a “DONE” where we learned about two identity properties you can use to check the “state” of your form. With this knowledge we can now build rules to check if we’re just before the create-action or after. We can also use that same principles on a modal form behind an action button for the entity. Try it all out for yourself; Have a nice weekend…cheers! 🍻
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”?
