Can we have dmx-on:executing and processing here? It will be useful to have one even on executing rather to set on start, on success, on error event etc. : usage example for disabling element or showing loader during particular serverconnect executing. I know there’s state:executing from dynamic attribute, but I think it is useful to have it set from here too.
I don’t think an executing event makes sense.
The event start is enough. If a form or server connect has invoked start event, until it invokes the done event, its in executing mode.
You can, for example, show a loader on start event. Then hide that on done event.
(Although, ideally for a loader you could just use a d-none class toggle on the state.executing property, and you don’t need to rely on events.)
Start and done are ALWAYS fired irrespective of the outcome being success or not.
If you use on start, you also need to use on forbidden, invalid, error to hide the loader if it’s not success or done. Let say we have 1 loader for the page, on executing can be used to show and hide that 1 loader for many server connects.
Like I wrote earlier, start & done events are ALWAYS called irrespective of the status of response. I am not sure what server model you are using, but that is what my experience has been.
When you say to show & hide loader on executing event, how do you think you will do it? Executing EVENT means it will fire just once saying that its started executing. You will need an execution ended event to hide the loader.
So the whole thing sounds exactly like the start and done events that are already present.
Hence, no need for an executing event.
Well just use the dynamic show/hide attribute and use the executing state for the server actions you want to show the loader for. That’s why there are states available for the server actions…
I understand that’s the current workflow. Example scenario:
- Have a preloader on main page
- Setup 3 server connects on content page 1
- Setup 2 server connects on content page 2
- Go to the main page, on preloader1 properties > dynamic attribute > show > on sc1:executing || sc2:ececuting || sc3:executing etc. OR having different preloader for each sc.
The workflow that I propose:
- On any server connect > Dynamic Event > Executing > Show preloader1
Does it make sense? 
I personally think that having some default (global) SC actions would be useful that get applied to all SC events on a page
e.g. if any SC returns unauthorised you could set it to redirect to your login page, show a not allowed message or you could run a flow with conditions etc.
It would save a HUGE amount of time from adding the same on done/on error/on success… actions to each SC. I imagine it very much like the Globals section of the new API Server Actions
2 Likes
What you are missing here is that executing is an event that will fire just once, from what I know about events. Once the preloader has appeared on the page, it will not be removed once actual execution is complete.
And you will have to still go to the trouble of adding this event on all server actions.
Rather, the step 4 with OR operators is a better approach. There is only one place you need to make a change and not on every single server action. So executing event does not make sense yet. 
As cool as it sounds, its just as flawed as the new steps option in the server action Globals.
So far, I only know of one use case for global steps - security identity. That too is Wappler specific.
Besides this, it is very unlikely that there is a step that someone would want to run on every single server action in the project.
Similarly, every single server connect on a page doesn’t necessarily need events associated with them. And then there would be potential server model specific SPA & MPA problems to solve too.
The approach that would make more sense is library kind of thing. Set one or more “Unauthorized Events” on the page/project level client side library.
On server connect component, options can be shown below server action API for various events with a drop down to assign one from library.
I know I haven’t thought this through, since this will also have SPA/MPA issues and something else too definitely. But its an idea.
If I or someone else can think this through, a feature request could be posted.
1 Like
Hi siddhant,
I can think of a few examples of when having standard actions for Server Connect would be useful. For example, quickly off the top of my head:
- If a SC step fails or condition isn’t met an error response is returned would show with the text set for that error response. This could be a toast/notification/bootbox
- If a SC succeeds, a flow condition looks for the existence of a success message (I set a value with the same name in SC actions that make updates to the database when, for example the insert id is present). If present a success notification/toast/bootbox is displayed with the returned message.
- If many actions exist on a single SPA/MPA page that a use is not likely/may not navigate away from regularly (highly possible in admin systems) you might need a response to unauthorised beyond the PHP page security restrict as that only triggers when a page/route is reloaded.
The only way, so far, I have found of achieving this is to add the same code over and over to SC on the page. However, if I want to change the process, I have to manually change every single one individually. I can’t just find/replace as many will have been supplemented by specific actions to that SC.
I completely agree with the idea of having a standard set of actions. Which is why Flows exists. And can be helpful for the cases you have described. You wont have to write and maintain the same code on every SC separately. You should try that in case you haven’t tried it already.
The issue that I raised is if it is implemented in the manner that Global Steps are - i.e., those steps run for every single server action in the project - it will mean the unauthorized/success/forbidden would get applied to all SCs irrespective of weather or not a SC actually needs that.
1 Like
Understood. But I would happily have it run on every SC in my project. You can then filter specifics or look for values to trigger success messages etc. with conditions. At least I would know that, if for example the SC was triggered for a user whose login session has expired (while still being on the same page), would be redirected to login every time. Plus I wouldn’t have to add the same success/unauthorized/error code, even if it is running a flow, to every one. That kind of repetition, in my mind, should be automated.