I have to create a lot of Server Actions to dynamically provide multiple options for forms. So that if options have to be added or deleted to a checkbox or dropdown form I only have to edit the single table that dynamically provides those options.
It would be a very handy Shortcut to simply select a Server Action in the API column and Drag it straight into my page code header.
Shortcut aside, (which is a nice idea), why not use one table with a keyed column that can be used everywhere. Far fewer database connections, client side filtering is fast, etc…
Thank you for your response, @scalaris
Would you demonstrate your idea in practice?
Wappler marketing emphasizes “drag and drop” functionality.
Usually this means that if you see a component in one column, as in my screencapture, you can literally select it and mouse drag it into the web document.
Even now without drag & drop, if the server action save included another checkbox “Add to target page” or “Add to open page”? Next to Output and Debug.
Hi! My app is full of dynamic stuff created by users which needs binding in forms and other stuff. The best is to use a db table with a “key” column and a “value” column as mentioned by scalaris.
I grew up with 90’s Macintosh Drag-and-Drop, so I was also really confused by this description in the Wappler marketing. Although maybe there are places where Wappler allows drag and drop, I think the description just sets the wrong expectation for users like me … and maybe you?
I haven’t found drag and drop to make sense as an overall description for Wappler, although I think it is awesome regardless!
I believe that’s not the case any more. They dropped that term.
I still don’t understand specifically
why not use one table with a keyed column that can be used everywhere. Far fewer database connections, client side filtering is fast, etc…
How many tables do you use to store data for your lookups and drop-down selects?
Oh, THAT idea!
Yes, pull one table in at once and use it to feed the values each form input requires.
It does make more work for ME on the filtering side of things.
I have to provide separate filter queries on the browser side to populate a checkbox group with 7 text options while the next form input has a different set of options, etcetera.
I know how this would work but in the time I was given to get it online for employees in the field to start using it – I went quick & dirty. A small table for each different form input to dynamically populate the checkboxes, radio buttons, sliders.
Then I didn’t have to write filtering queries to only expose the relevant rows & columns in a one table-fits-all dynamic source table.
Plus, on the Office Admin Dashboard I wouldn’t have to duplicate that on update inserts so that the Admin could quickly delete or add new dynamic entries to one category of input out of 10.
YET, what you suggest (I imagine that is what you suggest) makes plenty of sense. I will probably switch to this standard procedure this month on my next project!
The data view makes this fast end efficient
Well, I am certainly one who requires fast and efficient.
Although I can manage to slow down the term “fast” and clog up the meaning of “efficient” when I am using Wappler 
You’re not alone in that regard
