CurrentForm.controls vs. Request.variables

[Bill Parker]

OK, this is anal, but I would like to make sure I understand this, and the help file is a bit thin on it.

Using the dlg_EditAddUser component sample to add a user to security, I track the following values.

VALIDATE event, part 1

    dlg_EditAddUser Validate, before save user values
request.variables.ulink= test-test12
request.variables.guid= 
request.variables.userid= [email protected]
CurrentForm.Controls.ulink= test-test12
CurrentForm.Controls.userid= [email protected]
CurrentForm.Controls.email= 
CurrentForm.Controls.guid=

Above it looks like as I type values for the controls on the dialog, that also fills values for request.variables... There is no value for CurrentForm.Controls.email yet because it is a hidden control with no user entry.

VALIDATE event, part 2

    dlg_EditAddUser Validate, after save user values
a5ws_save_user_values(CurrentForm,request)
request.variables.ulink= test-test12
request.variables.guid= 
request.variables.userid= [email protected]
CurrentForm.Controls.ulink= test-test12
CurrentForm.Controls.userid= [email protected]
CurrentForm.Controls.email= 
CurrentForm.Controls.guid= 35582dd786584ed1a38f6afd6afd3c36

I am suprised by 2 things above. 1. After creating the web security record, CurrentForm.Controls.guid is now filled, before I "get" user values. Why is this? 2. request.variables.guid gets no value as a result of CurrentForm.Controls.guid being filled vs. when I type a value. Is there logic here or "just the way it is"?

AFTERVALIDATE event, part 1

    dlg_EditAddUser AfterValidate, before get user values
request.variables.ulink= test-test12
request.variables.guid= 
request.variables.userid= [email protected]
CurrentForm.Controls.ulink= test-test12
CurrentForm.Controls.userid= [email protected]
CurrentForm.Controls.email= 
CurrentForm.Controls.guid= 35582dd786584ed1a38f6afd6afd3c36

Values are the same as they were left in Validate, so all is fine.

AFTERVALIDATE event, part 2

    dlg_EditAddUser AfterValidate, after get user values
a5ws_get_user_values(CurrentForm,request)
request.variables.ulink= test-test12
request.variables.guid= 
request.variables.userid= [email protected]
CurrentForm.Controls.ulink= test-test12
CurrentForm.Controls.userid= [email protected]
CurrentForm.Controls.email= [email protected]
CurrentForm.Controls.guid= 35582dd786584ed1a38f6afd6afd3c36

request.variables.guid was not filled, so are only the "controls" filled by a5ws_get_user_values()?

Bill.

[NoeticCC]

Re: CurrentForm.controls vs. Request.variables

I could be wrong but doesn't request refer more to the page whereas currentForm is for grid/dialog elements?

[JerryBrightbill]

Re: CurrentForm.controls vs. Request.variables

CurrentForm.Controls is a placeholder for the controls in a dialog component. These are outputs from the a5ws_get_user_values() and a5ws_save_user_values() functions. The a5ws_get_user_values() function populates all controls that are valid for the current security configuration. The a5ws_save_user_values() may output error messages for a control (CurrentForm.Controls.control.has_Error) or may send a blank return value for invalid input values.

As stated in the help, Request.variables contain all variables sent from the client when the page / component is submitted. These are input values to the functions.

[Bill Parker]

Re: CurrentForm.controls vs. Request.variables

Thanks Jerry. I may be in a minority, but I am asking because (what I have found in) the help file did not clear it up for me. The thing I have to keep straight (and that I am still sorting out) in a client/server environment, is the detail of how the two sides talk to each other.

As stated in the help, Request.variables contain all variables sent from the client when the page / component is submitted. These are input values to the functions.

So when I type into fields in a dialog, that is entering a value into request.variables.mycontrolname, which is ultimately sent to the server. In the page before going to the server, does currentform.controls.mycontrolname exist or it it only created on the server? (I know I am incorrectly using "pointer" terminology to refer to whatever is on the client.)

CurrentForm.Controls is a placeholder for the controls in a dialog component. These are outputs from the a5ws_get_user_values() and a5ws_save_user_values() functions. The a5ws_get_user_values() function populates all controls that are valid for the current security configuration.

Would have been helpful for me if help file said CurrentForm was output from function, and contrast it to "User Values" output. Is "placeholder for" the same thing as "pointer to"?

If I want to refer to a control value, i.e. the value sent TO the server, in my xbasic script it sounds like request.variables.mycontrolname is technically the one to use. When is currentform.controls... given it values? When my Validate script runs, currentform.controls... already have the same value as correspoinding request.variables..., so could either be used? Probably some reason why not?

The a5ws_save/get_user_values() use "request" as input, and output "currentform". But a5ws_save_user_values() did not fill CurrentForm.Controls.Email, while a5ws_get_user_values() did fill this control. This is confusing to me. (My first post did not show the line
request.variables.Email = alltrim(request.variables.userid) before I saved to security.)

Finally, when I do a5ws_get_user_values() and multiple input values have been set, would the function search first for request.variables.guid, then userid, then ulink in finding a match with existing records?

Bill.

[JerryBrightbill]

Re: CurrentForm.controls vs. Request.variables

A5ws_save_user_values() only outputs limited values. Its purpose is to validate and save values. It will blank some fields that were invalid, such as an invalid userid or password by returning the blank value in the relevant CurrentForm.Controls control value. It also can output errors such as CurrentForm.has_error or CurrentForm.Controls.ControlName.has_error. To get the saved values, you have to use the get function.

When you type into fields in a dialog, they only exist on your computer until the page is submitted. When it is submitted the server places all submitted values into variables referenced by the "request.variables" pointer. For example, if you submit a field named "email" the value you entered will be found in "request.variables.email". Where it can get confusing is that you can also reference the value in a component event or web page with just the variable name, in this case "email"

When a component runs, all of the request.variables filled by the server are sent to the component when the component loads. In a dialog, those values are then placed into fields using the CurrentForm.Controls pointer. The CurrentForm.Controls pointer only exists in the component server events. When the component runs, the values referenced by CurrentForm.Controls are placed into the actual html that is sent back to the client

The security functions can only use the request.variables as inputs. The functions never use CurrentForm or CurrentForm.Controls as inputs for fields. Under certain conditions, the save security function may read a column heading from CurrentForm.Controls, but that is the only thing it reads.

Once you are working in the dialog events, you can add values on the server side using CurrentForm.Controls. For example, you may want to place a default value into the email field, so you could use this

CurrentForm.Controls.Email.value = "[email protected]"

While the help examples show you can also override values sent to pages and components in request.variables by manually changing a request.variable value, this is normally bad practice. In some future version, request variables may become read only. We will be releasing security functions that have a dedicated input parameter so there will be no reason to manually set any value for any variable in request.variables. These functions will be nearly straight replacements for the existing functions, which may become deprecated. The new functions already exist in both A5V8 and A5V9, but have not been documented.

[Steve Wood]

Re: CurrentForm.controls vs. Request.variables

Jerry,

On a registration page for instance, wouldn't you always need to manually set request.variables.email if the userid was an email address?

request.variables.email = currentform.controls.userid

Else you would have to ask the user to enter their userid, and then a redundant email address (assuming for the sake of argument you wanted to force them to be the same value).

[Bill Parker]

Re: CurrentForm.controls vs. Request.variables

Thanks Jerry (and Steve) for all your contributions. I still have questions, probably because of semantics, but I guess it is too much to resolve here.

I need a deeper understanding of all of this, and much of the documentation is at too high a level, e.g. a5ws_save_user_values(). "only outputs limited values" is at that high level, although I did not expect you to document it here. Trial and error is then needed, but that is more difficult and time consuming than on the desktop side.

Bill.

[Steve Wood]

Re: CurrentForm.controls vs. Request.variables

Bill,

This recent post of mine goes part way to explain how the function works in the context of registering a new user. The upper part of the post is specific to the users question, the bottom part more generic.

http://msgboard.alphasoftware.com/al...1&postcount=16

[Bill Parker]

Re: CurrentForm.controls vs. Request.variables

Steve,

That post was very helpful when I read it previously. That got me over the first hump, particularly in understanding why the a5ws_get_user_values() in the AfterValidate event, and ultimately led to my starting this thread. Looking back over it, I am supprised that I did not post my appreciation in that thread.

In another thread you said

The key to being inventive it [sic] to know how Alpha Five works, not just working with Alpha.

There are too many cases where the Help file gives the latter and not the former. I don't underestimate the huge challenge and cost of Help files, as I face the same issue in my own apps. But it greatly reduces my productivity, not to mention creativity.

This and other threrads have helped, but I still do not feel "unleashed".

Alpha might be able to leverage their documentation budget by starting a "recommended reading" topic in the Help file if there are non-Alpha books that can jump-start our general understanding and be compatible with the WAS approach.

I will have to admit (assume) that there is very helpful info in the Help files that I have not found. I don't know whose fault that is, but I sure miss the days when a printed version of the documentation was not 10,000 pages. (The large amount of white space makes it a bit unmanagable.)

Bill.

[JerryBrightbill]

Re: CurrentForm.controls vs. Request.variables

The limited values that can be outputs from the save function are the error messages. The statement that it can return blank values for invalid inputs is incorrect.

[Steve Wood]

Re: CurrentForm.controls vs. Request.variables

Sorry Jerry - are you referring to my referenced post, or something in this thread. I can't find where or who made that statement. If me, I'd want to correct it.

[Steve Workings]

Re: CurrentForm.controls vs. Request.variables

Well, I have now fiddled with a5ws_save_user_values() for about a week for one page for one customer, and still coming up short. Read, re-read, and re-re-read everything.

I'm using the WebDemo WebUsers.A5W page as my base.

From Interactive:
?a5ws_user_file_field_list()
= Guid
Password
Ulink
Userid

Dialog fields include:
guid (hidden)
Ulink (hidden)
UserID
Password

Validate event is:
currentform.Controls.Ulink.value = currentform.Controls.password.value
a5ws_save_user_values(CurrentForm,request)

The UserID is a valid email address.

Web Security Configuration has absolute minimal, non-restrictive requirements for the password.

The security record is getting created, with only the UserID. Ulink and Password fields are blank. And, the member_info.dbf record isn't getting created either.

Anyone have any thoughts?

Thanks.

Edit: I just realized I posted this in the V8 section, but I'm using V9. Should make no difference - I just wanted to stick with a similar thread.