> 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 ;-)
Therapy... I could use that :) > 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. Ok, gotcha :) > 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. I absolutely agree. I also have to say I've only toyed with Tiles superficially, so any discussion that brings that in I'm a bit out of my element with. I don't think that applies here though. It is true however that for any given page, it's only going to use a single Form Bean, as far as Struts goes. What I mean is, unless you yourself pass more beans (as I do in one app, via the request object), Struts only allows for a single Form Bean, per page, per request. This is, I think the relevant point for this discussion, even though we now agree Donnie wasn't actually asking how to access the Form Bean :) Indeed, if there could be more than one bean available, the question would be more difficult because now you'd also have to ask which bean to go after in addition to what name to use and in what scope. > The bean is available without being imported. It is in scope because > of the framework. Right? Importation is just for identification. Yes, after I wrote that I was worried the use of the word import would be confusing... I didn't mean to say or imply that you had to import anything... I was using it to refer to one JSP including another... That's something like an import... Bad usage of the term :) > 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 If I'd have known that I could have been beating up handicapped kids for the holidays all through school :) Would have been a great present for them! > True, but all Donie wanted was the *name*, which is passed to the > ActionForward in creating the ActionForward. Yep, I WAS playing the Scottrade guy... Always trying to give more than is requested :) > This is where we were parting ways. Donie just said he wanted the > name. So, that is what I have focused on. I'm with ya :) > Yah. I think we've got this down alright? For the sake of ever seeing this thread die, I agree :) > 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. I've written a couple myself as well. To say I never use them wouldn't be accurate, but to say I think of them first in any given situation also wouldn't be accurate. Then again, my environment is not one where we separate page developers from business class developers (although we may be moving in that direction). In such an environment I suspect I would be more in favor of taglibs as I think that's where they really start to "pull their weight", so to speak. Absent that situation though, I find them more trouble than they are worth 8 times out of 10. > I am surprised at this. I like them for what they are worth. Why do > you hate them? Well, I think my main objection is complexity. I think they tend to add more than they take away. So long as we're talking about purely presentational code, I don't have a problem with scriplets in JSPs, in fact I prefer being able to see precisely what's going on in one place without digging through some other class somewhere. Obviously you have to be careful not to let application logic sneak in. Taglibs are just more to configure and more dependencies. Not a huge amount I admit, but I'm a simplicity bigot, I like my apps to rely on as little as possible, have as few pieces as possible. I don't feel like taglibs do this, most of the time. As I said though, I DO use them when I think it's warranted, but they aren't my first answer to a given problem, 8 times out of 10. > 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. That's how I felt for a while too, but what I started to realize at some point was that if you let Struts do what it can for you, it becomes a little bit more than just a framework for using servlets. As an example... The app I was referring to that I converted to Strtus from a custom framework... Originally, each Action grabed all the paramters from request itself, did all the validations, stuffed things back in the form and stuffed the form in request or session for the view to use. That's typical servlet coding. So what was Struts really getting me, aside from the FrontServlet and config-based page flow paradigm? Not really much. But, if I instead let Struts auto-populate the Form Beans, and do the validation in them (the basic validations anyway), then my Actions become significantly more streamlined and less error-prone. True, I have to "trust" Struts more, and I don't trust other peoples' code very easily frankly, but the gains are significant enough to overcome that feeling. It's at this point that Struts becomes more than a framework for using servlets, and I think it's really the point of using Struts in the first place. >> >> 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. True enough, but then why use Struts? I'd just go off and create my own framework instead of Struts in that case. Oh wait, I did that :) That's what that app I was referring to was based on. Worked great, was all mine, might even have been better than Struts in some minor ways, but Struts has the upper-hand in so many other ways, hence the conversion. >> 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 Next time :) > Yes. You have the assignment of Dr. Strangelove: "Yes, Jack". My two > favorite words! LOL You know the stuff with Jack Ripper? LOL That movie has what is one of THE best lines in cinema history, top three in my book... "Gentleman! You can't fight in the war room!" That is so unbelievably classic! >> I loveses my request object :) > > Yes. What an object. So now we duel at 20 paces for the love of the request object :) >> > Tiger will figure out what an object is without the casting. >> >> Ah yes, the whole generics thing... > > This will be GGGGRRRREEAaaaaaaaatttttt!!!! Be careful... From all the concern voiced at the last Philly JUG meeting, I'm not as sold as you are. > 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. I personally think it will read to more difficult to comprehend code and code that is possibly more difficult to debug. But I could be wrong :) All I can say for sure is that I was far from alone in this thinking... About 500 other seasoned Java developers felt about the same way last week. It could be that you are just that far ahead of all of us and we'll come around eventually :) >> 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. I leave in a few hours, hopefuly the weather and traffic will cooperate. In the mean time I have to get some coding done :) > 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]
