Question

API_EditRecord with rdr to a different table where you API_GenAddRecordForm

Forum|Forum|8 years ago
February 7, 2018
0 replies
94 views

+6

AlinMihalcea1
Quickbase Alumni

Wanting to create a URL button that will edit a record using API_EditRecord and redirect to a new table where by using a API_GenAddRecordForm create a new record.
Is this even possible?

"javascript:if(confirm ('Are you sure you want to edit this record?')){location.assign('/db/" & Dbid() & "?act=API_EditRecord&apptoken=xxx&rid="&URLEncode([Record ID#]) & "&_fid_132=Canceled&rdr="&URLEncode(URLRoot() & "db/" & URLEncode([_DBID_STORE]) & "?a=API_GenAddRecordForm\n\n&_fid_151=" &URLEncode([Related Store #])&"\n\n&_fid_179=" &URLEncode([Related Project Quote])&"\n\n&_fid_437=" & URLEncode([Record ID#])& "\n\n&_fid_344=" & "Trip Charge"& "\n\n&z=" & Rurl())& "')}

This topic has been closed for replies.

C

ChadBrandmire
Quickbase Alumni
Forum|Forum|8 years ago
February 8, 2018

Use API_AddRecord not GenAdd

Like

A

anomDiebolt
Quickbase Alumni
Forum|Forum|8 years ago
February 8, 2018

>Use API_AddRecord not GenAdd

He isn't using "GenAdd" but you have identified the problem: The formula is unreadable in the formula editor and even more unreadable when posted into the forum.

Others may differ with me on this but any formula you write that has:

"javascript:" protoocol in it
JavaScript statements (eg confirm(), jGrowl)
API methods that return XML (most of them)
some redirection parameter (here "z")
the function URLEndode()

is better written as script saved in a code page. Get out of the formula language as soon as possible and execute your script from a code page.

I keep hearing the argument that you don't need to use script because we only need to use a small instance of one of the above bullet features. You are only causing yourself problems if you continue this practice. Consider these points:

Almost nobody can read these formulas easily
You will constantly be dealing with character escaping issues
Whenever you use one programming language to spit out another programming language (here the native Formula Language and JavaScript) you will have debugging and maintance problems - it almost does not matter what your skill level is - the mixing of languages itself invites the problems
If you jam your JavaScript code into formula you are just making the enormous set of tools that are available for working with JavaScript unavailable to you
Over the lifetime of your application your will have further problems when you come back to some mixed JavaScript / QuickBase formula to make the inevitable change new requiremetns require. In other words authoring mixed formulas does not scale well in terms of effort used to maintain them over the lifetime of you application
any redirection mechanism you use in your formula is only going to cause problems in the future - modern web application have evolved away from the practice of full page reloads where the URL changes with every action. If you need to string "actions" together you should be using script or perhaps using the back end actions QuickBase has implemented in Webhooks and Actions. Stringing actions together through redirection is not a best practice