My point though is... well, I guess now I have two :) First, every web
framework in existence can trivially support AJAX in whatever way one
wants because it's just an HTTP request.
Second, AJAX is in no way, shape or form anything new, revolutionary, or
a paradigm shift *except* to the extent that people have a higher
awareness of the technique now. And again, I'm not talking specifically
about the XMLHttpRequest object.
I can tell you from experience, over five years ago (I went back and
checked, it was 1998) I did an app that was *entirely* rendered
client-side... Let me describe it a bit because I think it's relevant to
this discussion...
First, the environment... this app was a web front-end to a COBOL-based
system running on a mainframe. We didn't have an app server available
at the time, all we had was a web server running in a UNIX partition on
the mainframe. I decided early on that CGI wasn't the way to go, even
back then. What we had was something called IBM Web Templates (IWT).
In short, IWT is an IBM product that talks to COBOL programs, and then
you have an HTML page that you have tokens in, and those tokens are
dynamically replaced with bits of data the COBOL program returns. Very
much like having a JSP, but with nothing but EL available (and
everything is request-scope, there is no notion of session involved here).
Well, IWT was kinda cool at the time, but but returning actual HTML for
the user to see wasn't great, for various reasons. Long story short, I
decided that instead of returning whole HTML pages for the user to see,
as was intended with IWT, instead we would return nothing but skeletal
HTML pages that really just had a <script> section in the <head> that
contained Javascript variables with the data returned. It also had a
call to a Javascript function that fired onLoad(). Just to be clear,
this is basically all that was ever returned to the client:
<html>
<head>
<script>
accountNumber = "1234";
firstName = "Mike";
lastName = "Mike Bober";
</script>
</head>
<body onLoad="window.top.fraAPI.populateAccountDetailsScren();">
</html>
When a user first accessed this app, they downloaded about 300k of
HTML... this was a frame-based application, where two frames were hidden
... one contained the application's API, just a collection of
Javascript. The other was called the "fraLoad" frame, and I'll get to
that... one was considered the "main" frame, where the "dynamic" content
was displayed... others were a status frame, a dropdown menu frame and a
sidenav frame
What was loaded into that "main" frame basically consisted of about 25
<div>'s, all but one hidden at a time. These were the various screens
of the application.
So, what would happen is this... let's say the user is on the Find
Account screen... they enter an account number, and a form is submitted,
targeted to the hidden "fraLoad" frame. The server responds with that
simple HTML document with Javascript variables... the little onLoad()
function fires, calling the appropriate function for the screen to be
shown in the API frame, and essentially the returned Javascript
variables get copied to the appropriate elements of the appropriate
hidden layer. The current layer is the hidden, and the new layer shown,
which in this case would be a listing of matching accounts.
The effect is that a new page was loaded, with the new data returned by
the server. Now, I've simplified things a bit here, there was a little
more involved, but this was the core concept this app was built on.
See? It's really AJAX without XML and without XMLHttpRequest (so I
suppose we need another name!). In fact, it's in many ways taking what
we do today even further because every single possible screen of the app
is on the client after the initial load, it's just a question of
populating data and flipping layers. I can tell you that the
performance of this app is second to none, even the state-of-the-art
apps we're building today with a TON more hardware backing it up don't
match it. I mean, think of how much less work is actually being done on
the server, and how much less is actually being transmitted over the
wire. It's true there is more work being done on the client, so
performance depends a bit more on the client than usual, but on balance
it works out in favor of better performance.
It also made exposing parts of this app as Web Services ridiculously
easy... all it took was creating a new template on the server that spit
out XML instead of those Javascript variables.
The point again is that AJAX is nothing new, nothing revolutionary, and
nothing special. I've been doing it for at least five years, and I know
I'm not alone (nor do I think I was the first to do somethine like I did
all those years ago). It's only peoples' awareness of the core ideas
behind AJAX that has grown.
Frank
netsql wrote:
Frank W. Zammetti wrote:
what does this AJAX module offer that can't be accomplished outside
Shale with little difficulty? I ask because, AJAX being nothing but
normal HTTP requests, is inherently supported by any web framework in
existence today. Oh, don't get me wrong, there are some niceties that
a framework could offer... automatic parsing of XML for instance...
but aside from extras like that, there's nothing special about AJAX.
http://struts.apache.org/struts-shale/shale-core/apidocs/org/apache/shale/remote/package-frame.html
What's special about Ajax, that is fundamentaly diferent from the past
is that it renders on the client side. It's a steping stone to future.
It opens the door to client side.
w/ a dynamic view (Ajax to JDNC, or JDNC + embeded browser inside, etc.)
it be nice to have a stable middle layer. Spring I find to heavy, and I
CoR centric so... I will try to integrate SHale for my project and I
hope it works for me. Struts makes 0 sense for my current project.
(this may not make sense but it does to me and I find related:
"I think Bass is best beer". Anyone who drinks other lesser beers, is
lesser than me. :-) Where's the Miller girls in the fountin?
Note, this is an illustration, if you don't have Bass in your fridge,
I'll drink what you have in the fridge, realy!)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
