struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: Accessing my form from an included page
Date Thu, 23 Dec 2004 06:15:26 GMT
See within:


On Thu, 23 Dec 2004 00:16:57 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:
> 
> 
> 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.

Lord, Frank --- no worries.  One of the worst things is people who
take things too seriously and read jots and tiddles on these lists. 
Relax with me.  Sounds like therapy?  LOL  ;-)

> 
> > 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 :)

Nah.  He only assumed that is what he wanted in order to get the name
of the JSP page. He said: "I also want to access the ActionForm for
the current page so that I can
retrieve the page name to build up the breadcrumb. How can I do this?"


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

I did not mean that it was in the response object but accessed within
the object building the response object, as well as other places.

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

This is the misconception, I think.  ActionForms are not for pages but
for Actions.  A page can have a multitude of Actions and ActionForms
in any particular tile.  ActionForms are never tile or page bound. 
Indeed, I think, the same ActionForm and Action can be found in
various places in a single tile or page.  Right?  The ActionForm and
Action are part of the framework and not part of the view in the MVC. 
You know this I know.  I am just thinking out loud and not really
concentrating on the communication aspect.

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

The bean is available without being imported.  It is in scope because
of the framework.  Right?  Importation is just for identification.

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

Sure you remember the good part.  We have family here for the holidays
and people were laughing about the town pornographer of some years
past.  His son was blind.  How ironic, we thought.  Hmmmm.  Seemed
funny then and cruel now.  You have to have been there.  My wife's
brother was talking about how he beat up the blind kid in camp.  Turns
out this made the blind kid happy because he felt part of the group. 
God knows I must have really been part of the group under the measure.
 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.
> 
> 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.  

True, but all Donie wanted was the *name*, which is passed to the
ActionForward in creating the ActionForward.

> Granted it's trivial to get at the name
> of the JSP in the Action, so I agree, providing the name is very easy.

This is where we were parting ways.  Donie just said he wanted the
name. So, that is what I have focused on.

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

Yah.  I think we've got this down alright?
> 
> >>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 :)  

I don't know if I am a fan of taglibs but I develop enough of them
myself.  They are fairly easy to write once you get the hang of it and
I build a custom suite pretty quickly.

> 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 :)

I am surprised at this.  I like them for what they are worth.  Why do
you hate them?

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

He wanted the name of the JSP page.  Why I don't know.  I have to
admit that I cannot figure out what Donie wants at this stage or why. 
But he did say what he wanted was the page name.  That is why I said
that the page knows who it is.


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

Oh I have done that too.  I think of ActionForms more as data grabbers
and do not take them too seriously.  Struts is great but all it is is
a framework for using servlets.  A good one but nothing more than
that.

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

Yes.  Or create a little framework to do it automatically.

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

Yes.  100%  We agree.

> 
> >>>>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!" :)

LOL  Yes!  Dang, missed my opportunity.  I remember that line.  LOL

> 
> Your assignment for this weekend is to watch Airplane and Airplane II
> again and this time MEMORIZE THEM!! :)

Yes.  You have the assignment of Dr. Strangelove: "Yes, Jack".  My two
favorite words!  LOL  You know the stuff with Jack Ripper?  LOL

> 
> >>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 :)

Yes.  What an 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 :)

I must have miscommunicated.  I know that in spades.  

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

This will be GGGGRRRREEAaaaaaaaatttttt!!!!

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

This will change the entire scope of design patterns in Java.  The
impact will be absolutely huge.  I have been waiting for this for
years.


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

Yip.


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

Heck, all you have to do is ask the ActionForward what it is and that
has to be there.

> 
> >>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 :)

Mine doesn't.  I am not that smart.  LOL  Have a nice trip.

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message