RestoreValue(), GetSessionValue()

[Majodi]

Hi there,

Building an app goes real quick until you need to customize some things. Like hiding or priming fields. In a form I need to know the calling proc and some fields. I managed to get it working with GetSessionValue('_ParentProc') and with field priming (advanced tab). But I'm not very comfortable as I don't know:

what is set
where it is set
what is safe to use
when to use RestoreValue() and when to use GetSessionValue

I even noticed that when I use field priming the values are there (I used the formheading to show both values) but when I remove the field priming they are 0.

Thanks,

Majodi

[Bruce]

Hi Majodi,

>> what is set
>> where it is set
>> what is safe to use

_ParentProc is often set if one procedure is "embedded" in another. For example if a browse is on a form, or if something is a BrowseChild and so on.
If it's working for you then it's probably ok.

In general terms though, it's hard to be specific about what is set, and where it's set, since there's obviously a lot of things being set.
In general, you should always use items from the SessionQueue, not "field values". You should also set the session Queue, not "Field Values".

Of course, a lot of the "magic" is happening under the skin, and this can be disturbing because you can't see the "big picture". And understanding the whole big picture is also very complex. So the best thing to do is have a look at the generated code if you're not sure about something.

>> when to use RestoreValue() and when to use GetSessionValue

GetSessionValue gets a value out the Session Queue. You will almost always use this.

RestoreValue is used to set a file field to the "best setting". Specifically it uses the ValueQueue (ie something passed on the URL) if that exists. If that doesn't exist it uses the Session value. If that doesn't exists it leaves the variable alone.

In almost all cases you will use GetSessionValue, not RestoreValue.

In the case where you are expecting values to be passed as part of the URL, or a cookie, or POST data, then you may be tempted to use GetValue instead of GetSessionValue. In almost all cases where I've seen this done, it's wrong.

If you want to Store a Value into the SessionQueue (if the Value exists) then use a call to p_web.StoreValue('something')

So if you want a "best practice" bit of advice;
a) use StoreValue to "save" passed parameters and
b) Always use GetSessionValue (or GSV for short) everywhere else.

and remember
c) If you set a File Field to something in hand-code, do a SetSessionValue (SSV for short) of the field as well.

Cheers
Bruce

[Majodi]

Okay. The first part of your reply worried me a bit because of its fuzzyness <g>.

But I guess the message is to take control yourself and use the SessionQueue. Forgive me if this is a stupid question, but if I'm not doing strange stuff, i.e. stay within the same netweb app without disconnecting, one user has it's own unique SessionId during the use of the complete app (all pages served). Correct?

So if I put someting in the SessionQ from one procedure I can get it in another procedure. So I can signal values between procedures like Global data. Right?

I would expect a SetSessionValue and a GetSessionValue. But now you say:

>>If you want to Store a Value into the SessionQueue (if the Value exists) then use a call to p_web.StoreValue('something')

and

>>If you set a File Field to something in hand-code, do a SetSessionValue (SSV for short) of the field as well.

Could you elaborate a bit?

Thanks,

Majodi

If it's working for you then it's probably ok.

...

If you want to Store a Value into the SessionQueue (if the Value exists) then use a call to p_web.StoreValue('something')

So if you want a "best practice" bit of advice;
a) use StoreValue to "save" passed parameters and
b) Always use GetSessionValue (or GSV for short) everywhere else.

and remember
c) If you set a File Field to something in hand-code, do a SetSessionValue (SSV for short) of the field as well.

Cheers
Bruce

[Poul]

I agree, i had to pause and think about the flow of Bruces' reply, as i did not expect him to close with storevalue, but rather setsessionvalue.  I think he is related to the first part of your question where _parentProc was passed as a value.

Use GetSessionValue(gsv)  or SetSessionValue(ssv)
and in my experience you stay out of the deep end, as things become more "server oriented" . Yes, within a user/session context I *think* of  these as Global.

StoreValue and RestoreValue are doing simple assignments with a twist (see netweb.clw) and  probably a shorthand for  bruce, but for me causes confusion, unless you say, use them only in the right place, <g> Maybe it stems from my assumptions of what a value is, I am always interested in these discussions to clarify that understanding. I think of these to manipulate passed parameters - (that may be on the form, or in the url) but I don't think this is a complete thought as they work inconjunction with the sessionqueue.

Bruce once explained RestoreValue it to me as optional/overridable parameters!

I have found aside from the "plumbing" that Nettalk generates, I can get by without thinking about them (values) to much, and have moved to relying on sessionvalues more and more.

This view might be different if i wanted to my pages to accessed outside my app - where passing on the url was might be more important...

[Majodi]

Okay clear. I'll play around with this and see how it goes.

Thanks,

Majodi

...

Use GetSessionValue(gsv)  or SetSessionValue(ssv)
and in my experience you stay out of the deep end, as things become more "server oriented" . Yes, within a user/session context I *think* of  these as Global.

...

[Majodi]

Two additional questions:

What is the lifespan of a SessionValue? Is it killed only when the session is closed?

And what happens if the same "variable" name is used more then once? I had SSV in the %ProcedureSetup but of course in the web paradigm each procedure is closed and re-opened each time and so the SSV is called each time again.

Should I test if a value is already there or is this something the SSV method is doing for me?

Majodi

[Majodi]

I think this cleared itself, I now test if a value already exist, saw that in the generated code so I guess that will be the way.

Majodi

Two additional questions:

What is the lifespan of a SessionValue? Is it killed only when the session is closed?

And what happens if the same "variable" name is used more then once? I had SSV in the %ProcedureSetup but of course in the web paradigm each procedure is closed and re-opened each time and so the SSV is called each time again.

Should I test if a value is already there or is this something the SSV method is doing for me?

Majodi

[Bruce]

Hi Guys,

whew - lots of questions, let's deal with the easy ones first...

>> What is the lifespan of a SessionValue? Is it killed only when the session is closed?

yes, it's killed when the Session is deleted. For the rest of the time think of it as "global" but limited to a single "user".

>> ... one user has it's own unique SessionId during the use of the complete app (all pages served). Correct?

correct. The session variable is "global" across all procedures.

>> So if I put something in the SessionQ from one procedure I can get it in another procedure. So I can signal values between procedures like Global data. Right?

absolutely right.

>> what happens if the same "variable" name is used more then once?

Each Session Value has 1 name, so it's the same as a (global) variable. If you use it in 2 places, you're actually using the same variable.

[Bruce]

Ok, now for the harder bit... This bit is about the use of StoreValue, and RestoreValue.

a) they are not complimentary functions. In other words, one is not the opposite of the other. They perform 2 separate roles, and their behavior is not related to each other. Indeed RestoreValue is only used in a small number of special cases, and you should not need to use it much, if ever. On the other hand StoreValue is very useful, and something that should definitely be in your arsenal.

b) a "Value" in much of my discussion refers to a specific parameter passed in via the browser request. There are 3 "ways" a parameter can be sent - in the URL itself, as a cookie, or as POST data. Regardless of the way, NetTalk parses all 3 out for you and stores these in the "ValueQueue". Functions like GetValue, SetValue and IfExistsValue are all common when dealing with the Value queue.

c) The danger with Values, especially fi you are new to web programming, is understanding when they are _not_ available. Consider the following case;

1) a Form is called, with a bunch of Values as parameters

2) The user clicks on a lookup button, selects a record, then "returns to" the form by clicking Select.

3) At this point the original Values _do not exist_. Because the parameters passed from the _lookup_ browse are different to the values passed from the _original_ browse.

Thus it would be dangerous to use the _GetValue_ method at anytime during the Form. Instead you make sure he Value is in the SessionQueue, and use GetSessionValue instead.

Ok, here's the crucial bit...

the most common technique folk used for storing the Value was
p_web.SSV('parameter',p_web.GetValue('parameter'))

But this is wrong. why? Because if the parameter _does not exist_ then the _session value_ will be cleared. The correct way to write this code would be

If p_web.IfExistsValue('parameter')
  p_web.SSV('parameter',p_web.GetValue('parameter'))
End

Since I got tired of writing this out all  over the place, I created a single method call which effectively just does these 3 lines. ie

p_web.StoreValue('parameter')

helpful?

Cheers
Bruce

[Majodi]

Yes Bruce. Thank you!

Majodi

Ok, now for the harder bit... This bit is about the use of StoreValue, and RestoreValue.

...

helpful?

Cheers
Bruce