AJAX does not provide platform tools to implement business logic. Any AJAX application that does build business logic into it is badly mis-designed. AJAX just isn't the place to do that stuff.
You can delegate business logic, which is what tools like <bigwig> and PowerForms do. AJAX doesn't have much support for this, but you can do it - it's useful too. What AJAX mainly does though is to proxy business logic. The logic remains on the server, the logic itself is never deployed to AJAX, and AJAX just makes rapidly interactive querying of it. This is a good halfway-house - you trade bandwidth (pipes and servers) for simplicity. But none of this is moving the business layer into AJAX.
More obviously, relating "business logic" to "asynchronous connections" is just plain wrong. I appreciate the shortness of this article and the need to address the relevant audience, but why waste words on things that are irrelevant or just red herrings ? When did it ever take 3 seconds to move to a mouse, and haven't you heard of keyboard shortcuts?
Nor is AJAX particularly an MVC tool. We've got plenty of those already - AJAX is something new. Of course it can do that too, but that would be like explaining AJAX's masterful new ability to pass XML fragments around the web (oh, you did - funny you didn't mention SOAP). MVC is 20+ years old and we've moved beyond it. AJAX is the toolset so that you're no longer limited to a simplistic MVC and can do more interesting things through a smarter Viewer.
All I'm saying is you need code in addition to any AJAX implementation to actually do anything useful. You're going to need client sode code as much as you need server-side code - I'm talking about putting code alongside AJAX, not inside it...
With regards to some of your other points...
Sure on the SOAP front I could have mention the IBM work on using E4X for handling SOAP in AJAX, but I'm more of the opinion that AJAX is best for working with raw XML data-snippets. Until we get E4X into every browser we won't be able to handle the WS-* protocols that will be driving the SOAP world - at least not without massive and unwieldy libraries.
The three-second thing, well it was more about using AJAX for new user experiences. We need to experiment, and I found it an interesting attempt - and potentially useful for call centres.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
You can delegate business logic, which is what tools like <bigwig> and PowerForms do. AJAX doesn't have much support for this, but you can do it - it's useful too. What AJAX mainly does though is to proxy business logic. The logic remains on the server, the logic itself is never deployed to AJAX, and AJAX just makes rapidly interactive querying of it. This is a good halfway-house - you trade bandwidth (pipes and servers) for simplicity. But none of this is moving the business layer into AJAX.
More obviously, relating "business logic" to "asynchronous connections" is just plain wrong. I appreciate the shortness of this article and the need to address the relevant audience, but why waste words on things that are irrelevant or just red herrings ? When did it ever take 3 seconds to move to a mouse, and haven't you heard of keyboard shortcuts?
Nor is AJAX particularly an MVC tool. We've got plenty of those already - AJAX is something new. Of course it can do that too, but that would be like explaining AJAX's masterful new ability to pass XML fragments around the web (oh, you did - funny you didn't mention SOAP). MVC is 20+ years old and we've moved beyond it. AJAX is the toolset so that you're no longer limited to a simplistic MVC and can do more interesting things through a smarter Viewer.
(no subject)
All I'm saying is you need code in addition to any AJAX implementation to actually do anything useful. You're going to need client sode code as much as you need server-side code - I'm talking about putting code alongside AJAX, not inside it...
With regards to some of your other points...
Sure on the SOAP front I could have mention the IBM work on using E4X for handling SOAP in AJAX, but I'm more of the opinion that AJAX is best for working with raw XML data-snippets. Until we get E4X into every browser we won't be able to handle the WS-* protocols that will be driving the SOAP world - at least not without massive and unwieldy libraries.
The three-second thing, well it was more about using AJAX for new user experiences. We need to experiment, and I found it an interesting attempt - and potentially useful for call centres.