struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Accessing my form from an included page
Date Thu, 23 Dec 2004 05:16:57 GMT

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 

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
> 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.

>>>>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!

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

> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message