Store a variable around a message?
I have a class myClass that defines the post () and get () methods.
From index.html, I have a form with an action that calls myClass.post (), which grabs some data from the database, sets a couple of variables, and posts the user to new.html.
now, new.html has a form that calls myClass.get ().
I want the get () method to know the value of the variables that I got in post (). This is the main thing here.
I suppose submit from new.html creates a separate instance of myClass created by submit from index.html.
Is there a way to access the "mail instance" somehow?
Is there a workaround for this? If I need to, is there an established way to send the value from the post to "new.html" and send it back using get-submit?
More generally, I think I don't understand the life of my instances in web programming. In a normal interactive environment, I know when an instance is created and destroyed, but I don't get it when I only use a class through calls to its methods. Are these classes even instantiated if their methods are not called?
source to share
It is about creating a "session". That is, a way to remember the user and the state of their transaction.
There are several ways to deal with this problem, all of which rely on techniques for remembering that you are in a session in the first place.
HTTP doesn't give you any help. You should find some place to store the session state on the server, as well as a place to record the session identification on the client. Two big methods:
-
Use cookies to identify the session. Seamless and quiet.
-
Use a query string in the URL to identify the session. Obviously because you have
?sessionid=SomeSessionGUID
in your url. This exposes and annoys bookmarks a lot. After the session is cleared, you still have this session ID moving to people bookmarks. -
In limited mode, you can also use hidden fields on the form. This only works if you have forms on every page. Not always true.
This is how it works in practice.
-
GET response. Check the cookie in the header.
and. No cookies. First user. Create a session. Save it somewhere (memory, file, database). Place a unique identifier in the cookie. Answer knowing that this is their first time.
b. Cookie. Was recently. Try to get cookies.
-
Enter the session object. Respond using the information in the cookie.
-
get out. No session. Old biscuits. Create a new one and act as if this is their first visit.
-
-
POST response. Check the cookie in the header.
and. No cookies. WTF? Silly children. Get away from the lawn! Someone has bookmarked a POST or is trying to ruin your head. Answer as if it was the first time GET.
b. Cookie. Fine. Get cookies.
-
Find the session object. Find what you need in the session object. To answer.
-
get out. No session. Old biscuits. Create a new one and respond as if it was the first time with a GET.
-
You can do the same with a query string instead of a cookie. Or a hidden field on a form.
source to share
This is not an instance management issue. Since HTTP is stateless, your program is effectively stateless too. (For long running processes like GAE, you can do it differently, but I'm not sure if you need this complexity here)
You haven't provided any code, but I am assuming that you will receive a POST and then redirect to the results (which is GET). Therefore, you need to save the parameter easily:
def save_foo(request):
if request.method == 'POST':
save(request.POST)
return HttpRedirect(reverse(
'Some_Target',
{'bar': 'baz', 'foo': request.POST['foo']}))
else:
# do something else
This view, in the case of POST, causes the client to issue a GET request to any URL alias Some_Target
. And this GET will include the parameter foo
from the POST.
This is a single view solution. If you need this behavior on a project basis, you can use middleware for that. And this time, caching the variable makes sense.
There are two things that make me a little uncomfortable with this approach:
- Mixing GET and POST parameters. GET parameters should be used for instructions without side effects such as filtering. The POST parameter should be used for side-effect overlays, that is, to modify data. When moving a parameter from POST to get, it should be avoided IMHO.
- If we need persistence, using object instances (or function scopes, as in my example) is usually not a good idea.
- If it's insensitive information with lower storage requirements,
cookies
that's the way to go. They are a client-side persistence mechanism, so you can just capture them in the request form, and if you don't change them, they persist (until they expire). - If you require more control over saving, you should use local save mechanisms. Server cache (any type), file system, database ... Then of course you will need to filter for each user manually.
- If it's insensitive information with lower storage requirements,
I would avoid instance caching anyway.
source to share
HTTP , () , , , , . , , , , cookie , , , , . , , , .
With this in mind, your best bet is to include the request parameters in the page link that you get with the GET, encoding the variables you want to send to the "receive" page (make sure they are not sensitive, as the user can change them!). Then you can access them via self.request.GET in the get request.
source to share
I don't know specifically about the google engine, but usually what happens is:
The server will have some thread pool. Every time an HTTP request is sent to the server, a stream is fetched from the pool or created.
An instance of some controller object will be created in this thread. This object will decide what to do with the request (for example, instantiating other classes and preprocessing the http request parameters). Usually this object is the core of web frameworks. The request parameters are also repeated by the browser every time (the server cannot guess what the browser wants).
Web servers typically have state stores for objects in persistent or session state. A session is represented by a unique user (usually with a cookie or a GUID in the URL) that will expire after a certain amount of time.
Now, in your case, you will need to take the values you got from the first function, store them in the session store and in the second function, return these values from the session store.
Another solution would be to send the elements back to the page as URL parameters in the generated HTML from the first function, and then you get them back "as usual" from your second function.
source to share
OK - Thanks everyone.
I'll try some of these ideas soon, and get back to you all.
I seem to be able to get around some of these things by doing a lot of writing and reading from the data store *, but I thought there might be an easier way to save this instance of the class (I am trying to use my known technologies in a web environment that I have not yet fully understood).
* For example, by creating a unique record based on the data in the POST and allowing some variables to be "tagged". Is this bad practice?
source to share