Lisa Austin wrote:
...
Code that sets a String object as an attribute
...
He says
"From the session object, you can call the setAttribute method to set any object as an attribute of the current session. To do that, you specify a name for the attribute and the name of the object that you want to store. "
Does this mean that "productCode" is supposed to store the result of the variable "session"?
If so how do I declare productCode it initially ?
Stephan van Hulst wrote:No, the string "productCode" is the name of the attribute that you want to store in the session. The variable productCode is a reference to whatever it is you want to store as the value of the attribute.
You can set any object as an attribute value, and when you get it you should cast it back to the correct type. In this case, the product code is a String, so if you want to declare and initialize it in one step, here's how you would do it:
Stephan van Hulst wrote:No, the string "productCode" is the name of the attribute that you want to store in the session. The variable productCode is a reference to whatever it is you want to store as the value of the attribute.
Junilu Lacar wrote:
Lisa Austin wrote:
...
Code that sets a String object as an attribute
...
He says
"From the session object, you can call the setAttribute method to set any object as an attribute of the current session. To do that, you specify a name for the attribute and the name of the object that you want to store. "
Does this mean that "productCode" is supposed to store the result of the variable "session"?
If so how do I declare productCode it initially ?
No, it doesn't.
Think of "productCode" as a sticky note. You're just basically labeling something, in this case the String referenced by productCode so that it can be accessed through the Session by something else later on. You would declare the productCode variable as you would declare any other variable in your program; there's nothing special about it.
This all has to do with context and visibility. Think of the Session as a bucket of "things" that are labeled with sticky notes. Technically, it's a Map<String, Object> but since you want to dumb it down, it's a "bucket" where you can put things (the Object values) that are labeled (the String keys).
I have to run out really quick but I'll continue this explanation when I get back.
Junilu Lacar wrote:As I was saying earlier, this is about context and visibility. There are a few contexts or scopes available: application, session, request, and page. Again, if you think of these as "buckets" then the main difference is basically how long these buckets keep their contents (the scope). Anything you put in the application context remains there until the next time the application is restarted or until that thing is deliberately removed. Things in the session bucket/context remain there for the duration of a session, which is a series of interactions with a web app over a specific span of time. The request bucket will only hold its contents for the duration of a single request.
Why do you need these buckets? Well, this is a way for different parts of your web app share objects with one another. It's a form of encapsulation although probably not strictly in the sense that you have in Java objects.
If you're familiar with those capsules that get vacuumed back and forth at your pharmacy drive-through window, that's kind of how this all works. The pharmacist is inside the store, and you're outside, separated by a wall and window. Between you and the pharmacist is this tube. The pharmacist will first put a capsule inside this tube and send it over to you. You take the capsule out of the tube at your end and put in your ID and credit card or cash. Then you put the capsule back in the tube and hit the button to send it back to the pharmacist who then checks out your ID, rings up your purchase, and puts your meds in the capsule. The capsule goes back in the tube and gets sent back to you and you take everything out and go on your merry way. That's what a "session" is like and the capsule that was going back and forth was your session context. The things that were put inside the capsule were the objects that you passed to "getAttribute" and "putAttribute". Just imagine that you and the pharmacist were really dense so that you also needed to put sticky notes on the things you put in the capsule so you could tell which one was the "card" or "cash" or "ID" or "meds".
The web application is what provides the infrastructure for all this to happen so you don't really need to worry about that, kind of like how the vacuum tube system and walls and windows already came with the building. It's just there for you to use.
Does that make sense?
Lisa Austin wrote:
If I WANT it to contain the value from how would I accomplish this?
Junilu Lacar wrote:Again, no, productCode is NOT the same as the session. The value returned by request.getSession() is a Session context. The session represents the series of related requests that the particular request object you're calling getSession() on belongs to and the session context is that "bucket" of things I explained previously that holds things for the duration of the session.
productCode is something that you'd like to make available to other parts of the web application via the Session context. Those "other parts" are usually other program modules that also have access to the same session, other servlets running in the same web application, or a JSP. As I said before, you would initialize productCode as you would any other variable in your program.
Maybe you need to step back and see the big picture to understand what's going on. Somewhere else in your application, there is code that needs to use that productCode. In order to do that, it needs to get a reference to that value. The reference gets shared (or going back to the capsule analogy, gets shuttled around) via the Session context. So one part of your program determines what the product code is, puts it into the session context, then another part of your program looks for the label "productCode" and retrieves the value associated with that label from the Session context. Then it can do anything it wants with it, usually display it to the user.
Yes I understand that. My previous response was just for acknowledgment to what you said.Junilu Lacar wrote:Again, no, productCode is NOT the same as the session. The value returned by request.getSession() is a Session context.
Junilu Lacar wrote:Again, no, productCodeThe session represents the series of related requests that the particular request object you're calling getSession() on belongs to and the session context is that "bucket" of things I explained previously that holds things for the duration of the session. productCode is something that you'd like to make available to other parts of the web application via the Session context. Those "other parts" are usually other program modules that also have access to the same session, other servlets running in the same web application, or a JSP. As I said before, you would initialize productCode as you would any other variable in your program.
Junilu Lacar wrote:
Maybe you need to step back and see the big picture to understand what's going on. Somewhere else in your application, there is code that needs to use that productCode. In order to do that, it needs to get a reference to that value. The reference gets shared (or going back to the capsule analogy, gets shuttled around) via the Session context. So one part of your program determines what the product code is, puts it into the session context, then another part of your program looks for the label "productCode" and retrieves the value associated with that label from the Session context. Then it can do anything it wants with it, usually display it to the user.
Junilu Lacar wrote:
Lisa Austin wrote:
If I WANT it to contain the value from how would I accomplish this?
Why? That's like putting just a sticky note in your bucket that says "Bucket (see the thing that you found this sticky note in)" - that seems rather silly, doesn't it?
Lisa Austin wrote:
I think I understand what you were saying previously. I'm not sure why I'm coming across as I don't.
I'm not currently coding an application but just trying to learn and understand the chapter itself.
Lisa Austin wrote:I was thinking that somehow this was supposed to be similar to to the previous chapters where I used the request.getHeader();
Junilu Lacar wrote:
That's fine, too, but the best way to learn how to swim is to get in the water and paddle around. Nobody has ever learned the breaststroke from just reading about it.
Junilu Lacar wrote:
Lisa Austin wrote:I was thinking that somehow this was supposed to be similar to to the previous chapters where I used the request.getHeader();
Going back to the capsule analogy, all this is doing is demonstrating that a context also has different "subdivisions" or "sub-compartments" that are used to organize things inside of it even further. getHeader() gives you access to information that came in the request header. These are kept in a separate "compartment" from other things within the request context.
Basically, what that code is doing is taking a value that's labeled "host" from the sub-compartment that contains things that came in the request header, and adding a copy of it to the collection of request attributes with a label of "Hostval", essentially relabeling the same value. Kind of like taking something labeled as "Meds" from one compartment in the capsule and putting it in another compartment labeled as "Medications".