Hi, Frank, Always good discussing these matters with you. I think you are going to get a kick out of the turn this reply to your response will get. I AM GOING TO REVEAL WHY I THINK THAT THE BASIC STRUTS ARCHITECTURE, AND .do IN PARTICULAR, IS THE WAVE OF THE FUTURE, NOT THE PAST. [Imagine "Mission Impossible" music in the background.] I have great faith in the Servlet, but not the JSP, idea.
I am going to tell you something that you might have missed. There is no need to have a JSP page to do this. This is NOT dynamic content. This is strictly HTML. So, the page that has this is not thereby crippled at all in this sense. There is nothing in using this that changes HTML to JSP or any other dynamic pages. That is the miracle of "returns null;" This is a different kettle of fish. Please note, also that the HTML for the ResourceAction can access any server it wants. This is highly flexible, not staid and bound. ' The key here is the use of a PROTOCOL instead of a URL. What happens when you do that is not immediately obvious. Personally, I avoid URLs whenever possible as they merely couple your work to options you probably will frequently wish you did not have to take. Read on! <snip> On Sat, 29 Jan 2005 20:10:08 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Lo, Frank. You really don't lose anything. You just gain a choice. > > There is a lot more to be said on this, but you probably would know > > everything on this anyway, so I will leave it at that. > > That's not strictly true though Jack (neither your premise that you > don't lose anything or that I know everything about this, I almost > certainly don't!)... > > In some environments, as I'm sure you know and probably have even dealt > with, you have a bunch of web servers in front of a bunch of app > servers. The web servers serve static content like images, stylesheets > and usually server-side includes, things like that, while the app server > handles JSPs and actual server-side (servlet) code. </snip> The ResourceAction requires Struts but does not require JSP. Cool? Remember that Struts has nothing to do with JSP, Velocity, etc. This is pure HTML requiring Struts. <snip> > Putting everything under WEB-INF removes this choice because every > request has to be routed to your app servers now. </snip> Surprisingly, perhaps, not so! There is nothing in an HTML page that has the Struts protocol for the ResourceAction code which makes that page dynamic, even though the content is. This is pure HTML. That is why it works so great inside Flash ActionScript too. You cannot, after all, put JSP inside Flash ActionScript. Frankly, no pun intended, Frank, I have considered doing all tags via something like this and through Struts Actions. That would mean that your page designers would have freedom you could not believe and that the same pages could work for any backend language. I have done some dabbling with this and have internally called them ProtoCallPages. I suspect the use of JPP (a sort of Action page language which is based on having to have the code off the page) in conjunction with Servlets is much better than in conjunction with JSP or other tag based ideas. We'll see in time. What do you think? I am sure that there are huge issues to consider but my experience with ResoureAction tells me that things might work out fine. I actually sort of compound JPP with some Struts form tags to get dynamic images with language, size, background and foreground colors (or images), fonts, etc. all dynamic but requiring only a protocol for my part. I have considered just droping the Struts part altogether and keeping JPP doing all the form stuff with pure HTML but with all the dynamic results you get from things like JSP, ASP, etc. Anyway, enough of this. Don't you know better than to get me talking? ;-) LOL That's why I love talking to you. You not only have a lot to say, you also listen. Nice combination! <snip> >In larger scenarios, > the whole point of the web servers (well, most of the point anyway) is > to offload that work from the app servers and gain efficiency. Division > of labor and all that jazz. :) </snip> Agreed, although I would certainly love to see a huge discussion by the mavens in the area on that one. I think that there is more than meets the eye to that. Still, however, agreed! <snip> > I'd certainly agree that if a particular situation doesn't call for such > a distributed environment in the first place, than it's a moot point, > and what you suggest certainly has some benefits. But if that's not the > case, or if it some day might not be the case (i.e., your app might have > to scale into such an environment), then it could become an issue and > people should be aware of it before they make their decision. > > I also don't know what effect this might have in a true distributed > environment (i.e., might it be a problem if one request, say for an > image, is serviced by one machine, while another services the JSP > execuetion itself?). This might never arise, or it might not be a > problem at all even if it does, but it could be something for someone to > explore is my point. </snip> Certainly there are things one would have to do in a distributed environment, but the fact that there is a complete decoupling by using a protocol rather than a URL makes all these problems easily solveable. You can do wonders with this sort of thing which you would never consider prior to doing this. You ought to try it on some project and watch where you will be surprised. This is so efficient and flexible. Remember, the code src='resource.do?file='my.css' is stricly HTML. Now, if someone wants to get in a fight, they will jump into the semantic heaven of debating what "strictly" means. However, please note that I am talking about syntax and not semantics. 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. We are poor . . . but we are free." ~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]
