Refresh Table on Server Side

When a form is changed in Wappler, it isn’t clear that making changes can break the $_POST variables in server connect. I had a major issue trying to get an image to upload, and it turned out that one of the variables had changed in relation to the form. While this may seem obvious in hindsight, I think it will confuse people in the future.

My suggestion:

  1. Add a update icon next to the word $_POST that shows only if a form is linked in the Global Input Properties Panel. Clicking this would refresh the list so that it was current with what is on the form in question.

  2. Add an update icon in the top bar. (See image for both examples.)

  3. When a form is linked in the Global Input Properties Panel, any destructive changes to the form will alert the user in an alert box that they have to click Okay or Cancel on.

While you could simply click on Globals again, and import all over again, I feel that putting a notification and the symbol (particular my first suggestion) would make it that much more clear what is happening or capable of happening. This will be helpful, I believe, to people that aren’t used to using DMX-Zone or aren’t seasoned developers. (Or just aren’t strongly familiar with Wappler yet…)

Thanks for considering.

Hello Chad,
That’s exactly how it is supposed to be done - when you change an input name:

  1. Select globals
  2. Click import from form

Easy as that …

Not to mention - you can manually add a POST var as soon as you add it on the page, if you don’t want to import the whole form.

Yeah I dig you can do that. But I think adding the refresh icon will make it more clear that changing the form means something needs to happen here. I don’t think it is a critical suggestion. Just thinking about making things more clear to people that have very little experience with Wappler or DMX-Zone.

there is no connection between the server actions and the pages.
you are responsible for organizing and updating (same as the naming of the server actions)

i don’t like this and i hope it will be improved in the future

@mrbdrm of course it works like that.
That’s the main idea behind separating back end from the front end.
You can use the same server action for different app instances/on different pages. You can call the backend API from several different front end views… This way backend code stays where it needs to be - on the server and not directly on the page.

@Teodor i know that the server action should never be changed based on a page since this is not logical.
but a warning will do the job

A warning about what exactly? It is you who bind the server action to a form for example. What should we show warning about?

a warning on the server connect on the page (the server action is expecting this but you are passing this)

That is input data validation in the server action. We already have it and you should always enable the validation of the input data (get/post) for the server action. Make always sure you specify which data is required and add extra data type validations.

From there you can sync this automatically with the client side form.

This way if data is not passed or with the wrong type you will see a nice message about it and don’t Need to dive in complicated debug logs.

1 Like

Here is the issue
there is no easy way to know that. i must upload every page and manually run each form to see if i get an error? why don't wappler make this simple test in the editor when im working on the page?
just like we can see javascript errors without uploading the page first and testing.

So you want Wappler to check which action files is used on which page and warn you if you change something/somewhere?
I don’t get the logic - what should we check? Form fields on the page? Post vars in Server Connect? How do we know that you are making a mistake?

that is a different request :slightly_smiling_face:
the ability to know where is this server action is used on my project.

this request is simply to check on the server connect component in the page if there is something not right on the submitted form fields and the expected variables on the server action.
for example a button to run the check on the selected server connect component in the page.