Adding parameters/values into the DB from a form submit that aren't on the form, e.g. like 'Current User' in Bubble

From Bubble to Wappler
#1

Hi there,

So, Bubble makes it incredibly simple to input data into the database, even if that data doesn’t exist on a form which is especially useful for relationships between tables.

E.g. if I have a form submit that just has one text input field and a submit button - on submit I can then add as many data points into the database as I like with a workflow. Most commonly I would add the table link and especially the ‘current_user’ and Bubble natively creates the time stamps.

What is the way I would do this in Wappler? I’ve been playing around with this for a bit but can’t seem to find how I would do it. I’ve created the form, connected to the database and then the appropriate table, made a server connect form and I have even managed to add {{TIMESTAMP}} into the Server Action for created_date and modified_date fields - but in terms of assigning the ‘current user’ and any related tables, I’m a little lost.

Can anyone point me in the right direction of something I can read etc.?

#2

Sure. Just think of a server action like a workflow or perhaps more appropriately an api workflow.

Within a server action you can have any number of database actions, external api actions, file actions, etc. However, unlike a bubble workflow, these actions are performed sequentially ( bubble workflows optimize themselves ).

It sounds like you’ve figured out how to connect a form to a server connect action, but you can also execute server actions without a form. On the client side you add server connect elements that either execute automatically or that you trigger as needed.

For current user, I use the security enforcer to get the user identity and perform a single query action to get what I need. If what I need is needed often, I set server session variables and reference those across server actions.

—Ken

PS you can have your db handle the created and modified fields so you never have to set those from Wappler… unless you want. :slightly_smiling_face:

#3

Also, depending on exactly what your needs are, I will often have a couple of input fields in my form that are hidden, and read only just in case.

This is a simple way to add any static or dynamic data to the form to be submitted without impacting the visual layout or what the end user can see.

Also, in the form update or insert step in your server connect side, you can insert or update records from data you get elsewhere (i.e. date/timestamps from a variable etc)

I think you’ll find there’s a few different ways to go about it, I’m no expert on which is best but that’s a couple of things I personally do.

#4

Thanks for asking such a great question!

A couple of things I would add to colour in Ken and Philip’s comments…

You can call a server actiont two ways - either by:

  1. Submitting a form - then the variables appear as POST variables on the server side
  2. Connecting it to a “server connect” on the client side that you then “load” - - then the variables appear as GET variables on the server side

Always make sure all your server side actions have the Security Provider and Security Restrict steps, and as Ken says, use the Security Provider to store the id of your current user… which you can then just select as you fill in the fields of new database records you create.

I use a lot of hidden fields as Philip describes… often loaded with a variable which will get set in different ways depending on how the user came to the form in the first place.

Good luck with it!

Antony.

#5

Thank you all - a lot of info here to digest, so I hope you don’t mind some follow up questions while I get my head around it all.

So as I understand it, for every action that I want to take I first need to query the DB to get the variables I might need to use, and this would be in each server action?

@mebeingken - can you advise how/where I set the rules for the DB to auto handle created and modified fields? (noting I’m using postgres and Heroku). Is this handled by Wappler in a setting somewhere?

@Antony - I’m hopeful that others will find my questions useful too, so it’s not entirely just for my benefit! Bubble is brilliant at simplifying things - it is a lot more complex in Wappler, but I can see the power that Wappler will have over Bubble, Bubble’s performance is a major concern for me - hence trying to build the app in Wappler as a comparison.

You mention always use Security Provider and Security Restrict steps for all server side actions - do you mind letting me know why you recommend that? And Security Restrict - is this essentially just to restrict page load for users not logged in? I’m building a SPA - and this seems a common issue - so still figuring that part out!

I’m going to try hidden fields as this has been suggested twice now, things like this decrease performance i’m assuming but hopefully not noticeable in any way.

#6

Sorry, not Postgres user. I have to assume it is similar to mysql though, where when creating a field in a table you set the default value to currenttimestamp() or now() or something similar. Same for update, except you add on update currenttimestamp(), etc. If for some reason postgres is different in that regard, you could use a trigger. I’m sure we have a postgres user that can chime in…

1 Like
#7

Using hidden fields is perfectly acceptable…just remember that just like any other input on a page, the user can manipulate its value if they really want to. For me, if the information does not NEED to come from the client, then I retrieve it server side.

And just a general comment as a user having built several bubble apps where I was constantly fighting performance (among other things.) We get incredibly hyper-sensitive to adding a field, performing a lookup, etc. but we need to let that go in Wappler…of course to a point. Should we be careful about adding things that will degrade performance, of course. Just don’t let it get in the way of making progress in your app! The speed improvement is dramatic, so focus on getting the job done and deal with performance issues if they arise (again I stress, there is of course a limit. :slight_smile: )

1 Like
#8

checked out postgres documentation, CURRENT_TIMESTAMP() is the correct for postgres if anyone is reading this. Thank you for pointing me in this direction, will use this from herein.

1 Like
#9

The reason why Antony was suggesting to put a security restrict on each server action file (not steps, just each server action file) is discussed in a few forum topics.

Basically every sever action file becomes (for my understanding) a JSON file file that can be accessed like an API. Basically if you typed in your we address with the path to where that server action is stored you return the results of that file (usually a db query)

If you don’t put a security restrict on each server connect file, then in theory anyone could access that data. Using the restrict can then ensure even if you typed the correct path somehow, you’d still need to be a logged in user to return the results.

1 Like
#10

Thank you! This makes sense and I’m glad to find that out now, rather than later in the project. I guess a good feature request (if it hasn’t been requested already) would be a global security / privacy control.

#11

It’s also good practice to not set the output flag on unless you want data returned.

1 Like
#12

Hey @Philip_J is it possible for you to point me towards a resource (I’ve tried searching) - where I can put a server restrict on an action file - I seem to only be able to assign a security restrict as a step.

#13

Thank you. Appreciate this guidance as well. Learning rapidly!

1 Like
#14

No that’s right, you just add it as a step, before any of your queries.

I was just pointing out you only add it once to each file, not to each step in your action file.

If that make sense?

1 Like
#15

That does indeed, thank you for clarifying!

#16

One thing that helped me understand how Wappler works was to browse to the server connect action file and seeing the output. There’s an icon to do that and you then see all the JSON which is returned by the file.

Screenshot 2020-07-02 at 22.59.49
Screenshot 2020-07-02 at 22.59.49800×196 16.9 KB

So it really is an API. Unchecking the Output option on everything would produce an output of just:

[]

And adding the Security Provider actions would prevent the script from running unless you’re logged in.

1 Like
#17

I forgot to mention that almost every app I build has a current_user server connect. I usually load it in a header, or some other common element. It does a quick query based on the security identity, and you can load anything you want into that…which is actually more flexible than bubble’s current user setup but not as readily visible (until you add it.)

3 Likes
#18

I do exactly the same @mebeingken. And Wappler picks it up in all the bindings lists so you can ‘grab’ any data you need on any page. I call mine LoggedInUser.

2 Likes
#19

Thank you @mebeingken and @sitestreet - this sounds perfect as a replacement of what Bubble does. Do you mind if I ask, where you put the server connect on the app connect side, just add it underneath app or you’l put it under header?

On the server side, if you need to gather data from various tables, will you run multiple queries through the multiple tables or run multiple single queries?

1 Like
#20

@mgaussie If I’m wanting it in all my pages then I use the SSI (server side include) to show the file in place. So I might have a file called _header.php and then include that on my pages. If I then edit _header.php, I’ll put an App Connect Server Connect on there which connects to my Server Connect script.

On the server side it can be done any number of ways. A query with joins in it, or a custom query if you want to do something more complex, or just have multiple queries. I don’t think there’s a right or wrong way, just whatever works best for the scenario.

1 Like