Radicore Forum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » RADICORE development » Framework » Maintaining state (Is Radicore's use of saving state typical of all webapps?)
Maintaining state [message #4812] Wed, 08 July 2015 16:10 Go to next message
rafs is currently offline  rafs
Messages: 69
Registered: May 2015
Member
It seems that Radicore saves the state of the page before going down into a sub-page, then loads the saved state upon return. I am wondering how common this technique is in other webapp frameworks. I took a webapp development class a decade ago and I seem to recall that we saved state by passing parameters into subpages, but I can't be sure.
Re: Maintaining state [message #4814 is a reply to message #4812] Wed, 08 July 2015 23:39 Go to previous messageGo to next message
rafs is currently offline  rafs
Messages: 69
Registered: May 2015
Member
Also, it would be helpful to me to see exactly what is being passed from one page to another. I could use a packet sniffer to check this out, but wonder if you haven't already written-up an explanation somewhere. (I see the UML diagrams you have, but it would be helpful to see the data that gets passed, and even how that relates to "$where" vs. $this->sql_?? statements.)
Re: Maintaining state [message #4817 is a reply to message #4814] Thu, 09 July 2015 05:49 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2367
Registered: April 2006
Location: Surrey, UK
Senior Member
I do not pass state in the URL as this is a MASSIVE security problem. A naughty user could change the URL and really screw things up.

I use the $_SESSION superglobal to maintain state between requests. There is a brief description at http://www.tonymarston.net/php-mysql/menuguide/appendixg.htm l

The $where variable is a string which be passed from one script to another.

The $this->sql_* variables are used to modify the SQL query which is executed in the current script.


[Updated on: Thu, 09 July 2015 05:50]

Report message to a moderator

Re: Maintaining state [message #4910 is a reply to message #4817] Wed, 12 August 2015 06:08 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2367
Registered: April 2006
Location: Surrey, UK
Senior Member
There is more information in Working with a stateless protocol which you may find interesting.

Re: Maintaining state [message #4937 is a reply to message #4910] Wed, 26 August 2015 21:46 Go to previous messageGo to next message
rafs is currently offline  rafs
Messages: 69
Registered: May 2015
Member
I am back to this. I have read about your use of $_SESSION superglobal to pass 'state'.
What is your advice on the best way to view the state info as each new script (page) is called?

I want to see what the $where contains that is being called for the new page.
The technique I am testing (with Eclipse) is to set a breakpoint just after the standard transactions controllers at the initSession().

There under $_SESSION >> 'pages', I see my new (child) page that is being called with a few items: task_id, task_array, pattern_id, 'mypage(link1)', but I am looking for the element that I selected in the parent, 'gid' = '1', but it is not there.

[Updated on: Wed, 26 August 2015 21:59]

Report message to a moderator

Re: Maintaining state [message #4940 is a reply to message #4937] Thu, 27 August 2015 06:08 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2367
Registered: April 2006
Location: Surrey, UK
Senior Member
If you look at the initSession() function inside include.session.inc you will see that it looks for an entry in $_SESSION['pages'][$PHP_SELF]), and then extracts $_SESSION['pages'][$PHP_SELF][$task_id] into a global variable called $script_vars. The contents of $script_vars is then extracted into individual variables such as $where, $search, et cetera.

There is a separate copy of $script_vars for each script and this is is constructed BEFORE the script is called by the calling script. This means that if script "A" calls script "B" then $script_vars for "B" will be constructed by "A" using the scriptNext() function, and this will include any arguments that need to be passed from "A" to "B". When control is passed from "A" to "B" the $script_vars for "A" will remain in $_SESSION so that when control is returned to "A" it will be able to resume from where it left off. When "B" terminates the scriptPrevious() function will cause $script_vars for "B" to be dropped (unless the "Keep data" option on MNU_TASK is set), update the $script_vars for "A" with any values that need to be returned, then cause "A" to be reactivated. Script "A" will then be able to resume from where it left off, but now it will also have any values that were returned from script "B".


Re: Maintaining state [message #4942 is a reply to message #4940] Thu, 27 August 2015 15:11 Go to previous message
rafs is currently offline  rafs
Messages: 69
Registered: May 2015
Member
Yes, this is good. Thank you. I am "watching" variables: $_POST, $fieldarray, $script_vars to see what is happening.
Previous Topic: pdf.styles.inc
Next Topic: Task ID/Script ID
Goto Forum:
  


Current Time: Fri Nov 22 01:36:02 EST 2024

Total time taken to generate the page: 0.01174 seconds