Dakota Jack wrote:
Frank,
Donie is getting more than was planned for out of us.
We're like that Scottrade dude that builds the log cabin for his buddies in that commercial :)
Before I go any further, let me be sure you understand something... If anything I say comes across like I'm talking down to you, that's not the case. I'm simply endeavoring to be as precise as I can. You quite clearly know your ass from your elbow :) Just wanted to be sure no offense is taken if I disagree with anything and don't state it as eloquently as I might like.
First, to be fair to Donie, the answer to his problem is clear. We are discussing somethings that are unnecessarily far afield. A servlet can clearly know its own name. And, since the servlet creates the response object and the html, it clearly can use that name anywhere it wants. Right? Whether there is an ActionForm, etc. are separate issues.
I'm not sure I agree... While I admit we have expanded the discussion here, and I'm not even sure I remember the original question :) ...
As I recall though, he was asking how he could access the Form Bean for a given JSP from an included piece of code. If this wasn't the issue, then clearly much of what I'm saying can be ignored :)
But if that WAS the original question, I think this discussion is very much on topic...
The Form Bean is in one of two scopes... request or session. It doesn't ever go in the response object (you have no further to look than an ActionMapping to verify this... scope can be one of two values as per the Struts javadocs, "request" or "session"). Perhaps a bit bizarre that response isn't involved based on it's name, but it's really not involved.
Now, the question becomes, under what name can that bean be found, regardless of which scope it's in. The problem is that Struts doesn't put all Form Beans under a common name, like, say, "form". It uses the name you specify in the <form-bean> element of struts-config.
So... Think of the code in header.jsp as a separate entity. It's going to be imported into various pages. So unless it has some way of determining the name of the Form Bean for the page it's imported into, it won't know how to get at that bean. Or, if the page it's being imported into makes the bean available before the header.jsp code is imported in some common way (i.e., it always gets it's bean into a variable named form... as long as the header.jsp code comes after that declaration and knows to always use the variable form, no problem).
So, I do actually think this whole discussion has been answerinf Donnie's original question, assuming I've remebered it correctly. Perhaps a long-winded answer though :)
Second, back to the fun stuff. Did you know that the sequel to the movie "Nerds" had the subtitle "The Odd Get Even"? LOL How about "Java Today, Tomorrow the Wurls"? LOL
I did not know that. That's pretty good! It's been a while since I've seen any of those movies, although I always remember the "head" nerd getting it on with a really hot girl in a moon bounce tent, or something like like that.
Third, prior to the activity reaching the Servlet, we can/may pass through an Action which has the name of the JSP page. Indeed, if we do that, the Action *must* have the JSP page name, because that is how the page gets called with the ActionForward completing the Action execute(...) method. Accordingly, providing the name is rather easy.
Not really true I think... One of the points of struts-config is so the Actions, the controllers in the MVC model, don't really know anything about the view, including the name of the JSPs. That's why you return an ActionForward, which encapsulates the target JSP, but the Action itself is ignorant of the JSP. Granted it's trivial to get at the name of the JSP in the Action, so I agree, providing the name is very easy. But again, assuming I'm remembering the original question right, that's not really much help.
You could of course reference the bean that the ActionMapping references and have each Action hand that off (through request) to the JSP, and in that way the header.jsp code could get the information it needs. This answer is basically a variation on a theme though.
Let's ignore any taglibs for the moment because it lets us get to the core of what's going on...
I am with you on that.
I'm not a fan of taglibs, but I've said that before :) Ironically, my current project I am deliberately focing myself to use them more than I usually would, just to be sure my knowledge and experience is decent. Then I can know even better what I am hating :)
If in a JSP I have the following scriplet:
<% SearchForAssetActionForm form = (SearchForAssetActionForm)request.getAttribute("SearchForAssetActionForm"); %>
This gets me a reference to the form for this page (assuming everything else is right... this is right out of a current production app, so it is). Also assume Struts 1.1, since I don't know what may or may not have changed since then.
As you can see, I have to know the exact name of the attribute in request (I did mean request) to get a reference to it.
Now, if we assume, using the example I had the last post in this thread, that this scriptlet were to be in header.jsp, which is going to be included in a number of different pages, obviously this is going to be a problem (null pointer... would it throw an exception? Not actually sure, but I digress...) This code really only should be in the page1.jsp (searchForAsset.jsp in this case), the header shouldn't know anything about the page it's being included in. In fact, it can't not specifically.
So, how to let the code in header.jsp get a reference to the above variable, assuming the above scriplet is NOT in header.jsp?
We are assuming that we need the name of the ActionForm. We don't. But this is interesting anyway. I am with you.
Well, I'm a bit lost... Are you saying we don't need the name of the ActionForm in general, or specifically to answer Donnie's question? If the former, I'd love to have you explain further. If the later, then it again comes down to whether I'm answering the real question or not. Maybe I'm not!
Three ways that I can see:
(a) Make sure the above scriplet appears BEFORE the include of header.jsp. So when the servlet is constructed, the variable is already declared when the code in header.jsp might make use of it. So now header.jsp just knows about a variable named form, and assuming it calls methods that would be common to all forms, no problem.
I am with you. I do this all the time with GUI methods that have differing values depending on the layout, etc. of the host. What changes is the value the method returns rather than the method name,etc. This works!
Sure does! I do this frequently as well.
(b) header.jsp can look at the ActionMapping, which I *believe* is in request as well, and use that to determine the actual name of the attribute to retrieve(SearchForAssetActionForm here).
How does the header.jsp know which ActionMapping is associated with the page? The ActionMapping is determined by the action attributes of the various forms which might be on the page. There is no definitive ActionMapping associated with a page, is there?
No, there's not, but the ActionMapping can be found in the request object, so you can get at any information it provides, including of course the Form Bean. I'm not sure this is a "safe" approach frankly, because the attribute name you'd have to look up could conceivably change in the future and break your code, but it is one possible approach. Better yet of course would be to add the ActionMapping to request yourself from an Action under an attribute name you like. That'd remove that gotcha.
(c) In all Actions always be sure to put a copy of the form in request under a standard name (like "form") and header.jsp can always go after that.
This is interesting. But, what good would that do? That would mean that you would have to access the form prior to the response object being created and independent of the request, right? This is just back to the beginning. What does "can always go after that" actually cash out to in this case?
Not true. In fact, an app I converted to Struts from a custom framework did nothing but this... The app didn't use Form Beans in the usual Struts way at all, that is, they were not declared in struts-config and no ActionMapping references them. Obviously they weren't being auto-populated and validated and all that good stuff. What happened is that the Action would instantiate the beans themselves and do whatever needed to be done with them, and then placed them either in session or request manually. This works just fine. It takes away a lot of the benefits of Struts, but it works (incidentally, the app I'm referring to I recently refactored to do things more the Struts Way(tm), so I'm quite intimately familiar with this.
If you do all this work yourself, you simply access the beans in the request object from the JSP page (via a line of code like the one I mentioned in my last response). Again, it's more work for the developer, but it works fine, and it winds up working like Struts does things anyway, just using different attribute names.
Me?!? A brain-fart?!? Surely you jest! ;)We might be saying the same thing in the end anyway :)
LOL I do, I do. I am jesting, jesting, I swear!
You missed it! You were of course supposed to reply: "No, I'm not jesting, and stop calling me Shirley!" :)
Your assignment for this weekend is to watch Airplane and Airplane II again and this time MEMORIZE THEM!! :)
Seriously though, I wasn't confused... Now, you may have an argument that I've been doing things in an odd way all along, I'm perfectly willing to entertain taht thought.
Yah. You are WAY too attached to the request object, mah mahn, mah maihn mahn.
I loveses my request object :)
Seriously though, the response is what gets returned to the client, so putting a Form Bean in response wouldn't really make much sense, since it's the JSP (usually) that creates the response, so it would need access to some object outside the response to get values from, like a Form Bean. A web browser, ignoring extensions and other hacks, wouldn't know how to deal with a Form Bean in the response, nor should it.
So, in actuality, I'm not overly attached to it, it's just necassery attachment :)
This is the part I don't understand... not the part about Tiger (although I'm not sure where you were going with that, but that's another discussion)...
Tiger will figure out what an object is without the casting.
Ah yes, the whole generics thing...
I attended the Philly Jug meeting last week where we had an evangelist from Sun down to proclaim just how great Tiger was, and give us a heads-up on it's new features. Well, let me just tell you... there was like 9 topics he wanted to cover... He got through exactly two of them. The second was generics (I forget the first!) and it slowed to a crawl at that point because people were hammering him with questions, complaints, concerns, etc. It was amazing. It was abundantly clear to me that generic, in some cases, can be a very nice thing. In others however, it's going to make life MORE difficult, not less.
My whole point is that the name of the attribute the form is stored under, forget about where that attribute actually is, is dependent on the page, usually anyway...
Initially it is just dependent on the ActionMapping, isn't it? You can change this, but that is the original deal. No?
Yep, you can change it however you want, the naming is up to you. But, a generic, shared piece of code that is reused on a number of pages doesn't *automatically* have any easy way, that I can see anyway, to know that name. That's where those three solutions I keep harping on come into play. There may be other ways too of course.
For any code in header.jsp to be able to access it, it has to somehow
know the name of the attribute.
You assume that we are trying to find the name of the form and that the form is the source of the name of the JSP page, I think? But, this is not necessarily true and probably not ultimately true in any case. Something has to put the name in the form and that is a better source throughout. The ActionForm is not a good way to get this?
That's a good point... I WAS assuming he wanted access to the Form Bean. If he wants the name of the JSP page, then he really needs the ActionMapping (assuming he doesn't want to write code to put the JSP name in request or all Form Beans). In that case your probably either talking about the slightly hacky method of getting the ActionMapping out of request, or adding it manually in all Actions under a more "static" name.
It can't usually know this except to know it for ALL pages, which means a giant branch logic, unless the element always has the same name, either by virtue of it beign declared that way in struts-config or by the Actions putting a copy somewhere under that common name.
Whew! It is too late or something. I am not tracking on this one.
No, it's not you :) I read that again and didn't know what the hell *I* was talking about for a minute!
What I was trying to say was that the header.jsp code could have a giant if block that checks for every single possible Form Bean. It should only ever find one, the rest should be null (assuming request scope here), so in that way it can determine which bean to grab. That's what I meant by it would have to know it for all pages, by virtue of that if block. Obviously that's about the least elegant solution, and doesn't take into account beans living in session scope, where you might sometimes have more than one.
Well, it IS late, that's for sure... I have to get ready for six hours of traffic tomorrow driving to New York. I should probably get some sleep. I'm pretty sure BOTH our brains hurt :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Jack
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation."
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
