Frank,
Donie is getting more than was planned for out of us.
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.
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
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.
> 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.
>
> 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.
> 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!
>
> (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?
>
> (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?
>
> >> We might be saying the same thing in the end anyway :)
> >
>
> Me?!? A brain-fart?!? Surely you jest! ;)
LOL I do, I do. I am jesting, jesting, I swear!
>
> 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.
> 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.
> 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?
>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?
> 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.
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]
