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.
I fully understand that. Keep in mind that a recent project I did required that images be served out of a database. To do this I wrote a BLOBServerAction that results in tags like this:
<img src="BLOBServer.do?table=logos%field=logo&query=where id='123'">
(with the query URL encoded of course). This is very much like what you do, except that my BLOBServerAction allows me to serve any BLOB-type from a database. Very similar concept, which is why I know where you are coming from full well.
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!
I can't say I understand what your saying here. Can you dumb it down a bit for an old man? :)
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.
Absolutely.
<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.
What I was getting at is the fact that if I return a page to the browser that have ten images, all referencing ResourceAction, what's happening is that the browser is making ten separate requests TO THE APP SERVER, whereas in a "typical" setup, these requests would be handled by the fronting web servers. It's clearly more resource-intensive in your approach.
As I said before, if your environment is a single server anyway, even if you have a web server in front of an app server, this probably doesn't make much difference, although it will always make some becuase the app server is involved instead of just the web server. That was my original point.
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.
Agreed. I do see the advantage of this approach, but it's the minuses I'm more concerned with. No matter which way you slice it, there's more server resources being utilized. That's a big minus when your talking about scalability.
What do you think?
I think you point out some valid advantages... if nothing else, just doing away with having to deal with URLs is a very good thing. But I think the performance hit, and certainly the server load, in a "typical" Enterprise environment, would make this not a great idea.
Then again, I say the exact same thing about ASP.Net and JSF because the whole idea of calling a server for relatively simple UI events strikes me as a horrible idea until we have far better networks than we have today, and I seem to be in the minority there, so if I might be wrong there, I might be wrong here too :)
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!
My wife wouldn't agree with the listening part :)
<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 think in enterprise-type environments this is a pretty standard approach with fairly well agreed upon benefits. Anything that breaks it has to exceed those benefits. As my father used to say, that's a tough nut to crack! Nothing wrong with trying to build the hammer though :)
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.
Absolutely it is, but as I pointed out, it's being interpreted on the browser side. That's where the issue comes in to play I think, especially in a distributed environment. I'd be interested to hear your thoughts on this point...
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
