|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 68
Messages: 68
Messages: 68
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Three forms of AJAX: solid, liquid and gas.
Looks like today AJAX concept have several different interpretations. According to the way applications use XMLHttpRequest, we can distinguish three main strategies of AJAX integration:
- Application-specific JavaScript that play a role of presentation controller on the client-side.
- Component oriented form
- Sub-page oriented form.
The first form refers to pure JavaScript developments. Solutions, implementing this form are the most flexible and powerful. They allow creating amazingly rich user interfaces. However, because of well-known limitations of JavaScript, they are quite hard to develop, debug and maintain. In addition, if multi browser support is required, you will probably have to develop a second AJAX-free version of your UI.
Component oriented form is both flexible and easy to maintain. Components do not necessarily expose JavaScript to developers, thus making their job easier. Auto-complete or auto-validating text fields, AJAX-aware trees and updatable data grids are typical examples of this approach. Its main disadvantage is the scope that rarely exceeds a single component (or set of similar components).
The third form is sub-page oriented form of AJAX integration. It refreshes "zones" on the page. While being less powerful then other forms, it is ideally suited for upgrading existing projects. It does not have visible scope limitations and preserves the original MVC architecture (presentation controller stays on the server side). Another advantage of this form is graceful degradation possibilities. The same presentation code can support both AJAX and traditional modes.
Unfortunately, all those forms seem to be mixed up under the same buzzword and compete with each other in developers’ minds.
It is important underline the possibility or even necessity of different AJAX forms co-existence inside a single application. Why cannot an application that already uses pure JavaScript form of AJAX take advantage of a ready to use updatable data grid component? Why should not an application, being migrated with AjaxAnywhere or DWR use AjaxTags or another great tag library?
Can we talk about layered AJAX integration, similarly to application layers?
|
|
|
Message #187854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Interesting Classification of AJAX
AJAX has surely rekindled everyone's interest in JavaScript.
This classification seems interesting.
|
|
|
Message #187857
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Like any new technology
Although the technologies that make up what's being called AJAX aren't new, like any new approach or technology, I think we're going to see the usual stages: initial excitement and a lot of frankly bad work being done; people will get a little jaded as they get stuck trying to maintain AJAX apps that were done ad hoc; tools, pre-built components, and standardized design approaches will eventually stabilize things and AJAX will become another commonly-used approach.
In the meantime, I think we all simply need to be aware of the existing limitations, and avoid creating massive AJAX apps lacking strong designs. Unless you like maintaining sites with pages containing many hundreds of lines of Javascript thrown in at random by inexperienced page developers!
|
|
|
Message #187860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
...it changes the developer skillset.
You wouldn't put up with html people playing in your Java foundation code, so why let java coder play in UI centric stuff?...
It changes the nature of the people that you hire. If you can't find people that already know JavaScript, DOM, etc, then you need specific skill people. People that are very good bug hunters and people that are generally bright to pick up new things. People that tend to "play" a lot more than most. You need someone that's ready to go up against JavaScript's little idiosyncrasies.
It's a different skillset, for a different app that really isn't just text processing in Java anymore (I know, there's more behind Html sites than processing text :) ).
Having written an Ajax framework for my company's projects, and having to keep worthy developers up to working on it... it's not an impossible thing. Familiarity certainly helps though.
But I'm firmly in the camp for super dynamic apps with fantastic functionality.
|
|
|
Message #187862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fourth forms of AJAX: band-aid.
I see Ajax as an attempt to cure syphilis with band aid.
There is a huge need for really dynamic and responsive applications, but they should be developed and modeled like Java Web Start applications or XWindow ones.
And JWS should be enhanced to be able to use central repository of common libraries ( log4j and alike) to avoid downloading them all over again even for tiniest JWS application.
|
|
|
Message #187865
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You are missing the point
Of corse, you are right... but only for the first form on AJAX: Application-specific JavaScript that play a role of presentation controller on the client-side.
There are, however, lots of possibilities to avoid massive JavaScript coding. What about AJAX-ready components? What about sub-page refreshing solutions, like AjaxAnywhere? They do not require JavaScript coding.
|
|
|
Message #187868
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Fourth forms of AJAX: band-aid.
I see Ajax as an attempt to cure syphilis with band aid.
I see Ajax, as just another tool in my client-side toolbox. Along with JSF, Swing, ASP.NET, Windows forms, Macromedia Flex, etc..
As long as every tool need a proper use, AJAX can be the best choise for some cases. Sometimes not. But to make a wise choise you need to understand all aspects and all forms of today's AJAX.
|
|
|
Message #187871
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: You are missing the point
I'm not missing the point. Someone brought up the developer issue that happens when you go the high level of Javascript category. I mentioned that it's a different skillset you need to find developers with.
I also said I'm firmly in the "very dynamic app, lots of JavaScript" camp... and everything I said supports it.
I'm very ready to realise that there are other forms that take less advantage of the client JavaScript abilities... so it's all about components that plug into the server, just need to write Java etc. That's cool. Let someone else do the script for you. If your team has no idea about complex JavaScript apps and making them work, then this is most definitely the option that a lot of shops should take. I'm all for it too. Componentised structure is excellent, love it.
The original item realises a reality that people are facing. They want AJAX, but don't want or can't handle the JavaScript burden. Some are willing for a little script work and so there's a middle road. All good.
I know exactly what the news item is on about, and I know exactly what of the three camps I belong to. I've made an AJAX/component framework back when there was nothing available, and the acronym didn't exist... I'm riding the bleeding edge... please don't discredit me by saying I missed the point. I'm all over this AJAX thing :)
|
|
|
Message #187872
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Model 1 and 2 all over again...
I think that everyone wants the first option, but the browser knowledge and DM knowledge and everything else is quite daunting to get up to speed with. There are many server side guys that know nothing of the client side. These guys are kind of high and dry with the first form.
The way to attack it, is frameworks that simplify and organise the client layer for AJAX. Plain javascripts going at it without organisation is pretty painful. What's needed is the organisation of the client side, similar to what we have on the server.
Model 1, JSP's just going for it on the server, gets very unwieldy. This is what most people see of the first option when it comes to AJAX. So what's needed, is frameworks that bring it up to Model 2 status.
Not so much MVC (but that would be nice)... but a componetised structure that allows the client screen resources to be more easily managed. For events to be more easily managed and handled.
For example... even just button handling events. In the framework I've written, we write component scripts. When you have a button, or an onChange event etc... rather than make another messy handler function next to all the rest, you just call out to the framework generic "doClick(this)" function. Every button on the screen does this. When the user clicks, the framework will find the component automatically, and call the "handleClick(button)" method for that particular component. Then the component can handle it.
This has been working for hundreds of components on the screen. The script component is a big plus. We have to write the client script for each components, but it's helped manage the client tier in terms of coding, and helping developers who don't know anything more than Javascript get a helping hand in being productive in the client tier. They just interact with the framework API.
So I say... it's that the custom scripts for the client side are unwieldy at the moment because they lack a framework to clean it up. Once it's cleaned up, you can have the high level of interactivity that everyone wants, without too much overhead in model 1 script woes.
Cheers,
Arron.
|
|
|
Message #187881
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
I classify Ajax applications as follows:
a) JavaScript clients: The bulk of the presentation logic is client-side, in your JavaScript code. Server-logic is relegated to data processing (ideally, sending/receiving XML data sets, but JavaScript-specific protocols like JSON are also possible).
b) Page-based applications with Ajax enhancements: A "traditional" web application, with some Ajax sizzle to make it better. This includes things like auto-completion, updating subsets of the page (like select lists or popups), etc.
I think both (a) and (b) are valid uses of Ajax. Personally, (a) is the one I am most interested in, but, there are many classes of web applications for which (b) is better (online shopping is a good example).
I do think that a component-based, "no Javascript" approach is viable for (b), but it will not work for (a). To write a real, Google-map style JavaScript client, you are going to need real experts in the client-side technology. It is not like JavaScript is rocket science; there are good books out there, and a competent server-side developer can master the technology in time.
Things will definitely get better, though, as the client-side frameworks mature and have better support for client-side MVC.
|
|
|
Message #187893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: You are not missing the point ;)
Maybe I should have said: "I'm not underlining my main point clear enough" ;)
And I agree with you on the need of client-side framework, but it's not an option today.
I also agree that everybody wants the first form, but the majority of teams cannot afford it.
I am currently involved in a sub-page oriented solution development. It seems to me that this form is simply ignored. However, this is what business often needs. The difference between 1-st and 3-rd is huge; presentation controller stays on the server-side. Team can take full advantage of the server-side MVC framework, without employing JavaScript gurus.
If you cannot do pure-JS, you can always do page zones refresh, and of course, you can add AJAX-ready components with their own JS inside. Customer will probably be happy with this.
Is #3 not complicated enough to be considered as "another form"? Maybe, but it's powerful enough to satisfy a lot of needs.
|
|
|
Message #187906
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
The third form is sub-page oriented form of AJAX integration. It refreshes "zones" on the page. While being less powerful then other forms, it is ideally suited for upgrading existing projects. It does not have visible scope limitations and preserves the original MVC architecture (presentation controller stays on the server side).
Oh, so you mean AJAX hasn't rendered server-side MVC frameworks completely obsolete? Hmm, that's too bad as these frameworks have all really sucked and made server-side development an order of magnitude harder than just developing business logic as simply pure SOA beans.
But this is just a transition, phase right? In the long run the MVC framework is none-the-less destined for the trash bin as users come to expect really cool behaving client-side experiences and page based web is viewed as ultra retrograde.
Think of all the thousands of projects out there that have joined their business logic at the hip to one MVC framework or another as they've overly coupled themselves to a specific UI approach. Server-side MVC frameworks have inevitably locked an entire web industry into poor server-side architecture that they'll be years crawling out of. But that is the monster that ultra thin client has wrought...
|
|
|
Message #187907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Odd...
Oh, so you mean AJAX hasn't rendered server-side MVC frameworks completely obsolete? Hmm, that's too bad as these frameworks have all really sucked and made server-side development an order of magnitude harder than just developing business logic as simply pure SOA beans.... This is a really odd statement to make and seems to stem from a lack of understanding of the purpose and application of current MVC frameworks. Clients built with these frameworks should ideally be consumers of your business logic and not implementers thereof. Most, if not all, of the popular/good MVC implementations say nothing about how you implement the business of your application, but are simply there to help manage the operation of clients consuming those services.
|
|
|
Message #187909
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re : AJAX hasn't rendered server-side MVC frameworks completely
Oh, so you mean AJAX hasn't rendered server-side MVC frameworks completely obsolete? ...
Great, you start seeing the difference between #1 and #3. All those things are still called AJAX. While the #1 is able (probably in future) to do the revolution of server-side architecture as you said, #3 does the opposite, it proposes an evolution.
Think of all the thousands of projects out there that have joined their business logic at the hip to one MVC framework or another as they've overly coupled themselves to a specific UI approach
That’s exactly what I’m thinking about. Even if they need AJAX, they still do not want to throw away their existing investments. Right? Then they pick #3, a sub-page oriented AJAX solution. If they want to re-write the application, they pick #1.
|
|
|
Message #187916
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
...he has a point
He does rbing up a fantastic point. Ajax, and throwing a lot of the smarts into the client, you can trivialise the web handling tier out of sight. Our Ajax framework does all the fun stuff, and makes what is akin to an RPC call direct into our business tier. There's very little handling that has to be done by the servlet. parse and map, and a few other small things.
If you have an SOA style business tier that fluently speaks XML... it makes fantastic sense to have the XML communication in AJAX speak directly to it.
Speaking for our project... we don't have an MVC web tier any longer... completely replaced with the above, and so far it's been a big success.
|
|
|
Message #187917
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
I had written a follow up a while back on a different approach that didn't involve so much overhead: JSF Avatar. Jacob
I read your post on Avatar but I don't see why your approach is better than the Atlas approach. I probably need to do a lot more thinking but could you possibly take a look at this:
http://www.nikhilk.net/AtlasProgModel.aspx and this:
http://www.nikhilk.net/AtlasArchitecture.aspx
and then tell me how Avatar is different?
Of course I should probably be doing this myself but since you seem to have already achieved the Ajax Zen, I could just stand on your shoulders and see farther ahead :-)
|
|
|
Message #187918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
I had written a follow up a while back on a different approach that didn't involve so much overhead: JSF Avatar. JacobI read your post on Avatar but I don't see why your approach is better than the Atlas approach. I probably need to do a lot more thinking but could you possibly take a look at this: http://www.nikhilk.net/AtlasProgModel.aspx and this:http://www.nikhilk.net/AtlasArchitecture.aspxand then tell me how Avatar is different?Of course I should probably be doing this myself but since you seem to have already achieved the Ajax Zen, I could just stand on your shoulders and see farther ahead :-)
Basically, there's less of a dependency on semantics within the client. A lot examples show extensive use of translating resources (db/file) to objects, then to communicate to the client, they again must translate to XML or some other format, then re-interpreted and re-rendered on the client. My suggestions within Avatar is that everything is retained at the server-- the rendering, coordination, etc, is retained within your OO code, the communication comes down to just being able to re-process parts of the view, like telling a Swing component to re-paint itself. I'm working on one such framework right now that is meant to work with existing MVC frameworks.
|
|
|
Message #187919
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
I had written a follow up a while back on a different approach that didn't involve so much overhead: JSF Avatar. JacobI read your post on Avatar but I don't see why your approach is better than the Atlas approach. I probably need to do a lot more thinking but could you possibly take a look at this: http://www.nikhilk.net/AtlasProgModel.aspx and this:http://www.nikhilk.net/AtlasArchitecture.aspxand then tell me how Avatar is different?Of course I should probably be doing this myself but since you seem to have already achieved the Ajax Zen, I could just stand on your shoulders and see farther ahead :-)
To elaborate a little bit more, the weakness in the transport layer, where your business models are more efficiently accessed on the server side-- while someone may believe having access to your models in the client may be the next big thing, really, you only want access to your models within the document you created on the server-- not the client-- JSP -> HTML. Then you start to look at if you were to have access on the client side to that model, how would you communicate it? And would it be any more efficient than just passing back the 'output' HTML? IMHO, I believe solutions that would transport model data back and forth would have a lot more overhead than simply calling 'methods' on the server side components and having them produce HTML back to the client-- maybe you don't need to have the whole object sent down for interaction with JavaScript, maybe on the server side, all you needed was the object's name to output. I dunno-- I'm rambling again.
|
|
|
Message #187924
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
down with JavaScript
AJAX has surely rekindled everyone's interest in JavaScript.This classification seems interesting.
AJAX would be a 100 times better if could dump JavaScript and use Ruby instead as the flagship client-side scripting language. And I have a "Trojan Horse" plan to do it:
When AJAX will truly be worthy of "Web 2.0" moniker
http://www.javalobby.org/java/forums/m91937075.html
This week-end at the No Fluff Just Stuff symposium in Seattle, I'm infecting the various speakers (who are now all fervently evangelizing Ruby) - such as Dave Thomas, Ben Galbraith, Bruce Tate, and others - with a virus of conspiracy that the next obvious move for Ruby and the advancement of Web 2.0 is to bring Ruby to the AJAX empowered client.
Of course with the "Trojan Horse" plan I outline, SVG, XUL, perhaps Flash, and a flull blown queued and publish/subscribe capable messaging standard could also be incorporated into the Web 2.0 standard platform. IOW, by end-running around the browser via the concept of the AJAX daemon and the AJAX Widget, the rules get completely rewritten in one fell swoop. The world of the Internet Web thus gets truly reincarnated into a 2.0 rendention. The Matrix is reloaded.
|
|
|
Message #187926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
My suggestions within Avatar is that everything is retained at the server-- the rendering, coordination, etc, is retained within your OO code, the communication comes down to just being able to re-process parts of the view, like telling a Swing component to re-paint itself.. You know what...it is called XWindows :)
|
|
|
Message #187927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
My suggestions within Avatar is that everything is retained at the server-- the rendering, coordination, etc, is retained within your OO code, the communication comes down to just being able to re-process parts of the view, like telling a Swing component to re-paint itself.. You know what...it is called XWindows :)
LOL, this will hopefully eat up less processor ;-)
|
|
|
Message #187929
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
down with JavaScript
AJAX would be a 100 times better if could dump JavaScript and use Ruby instead as the flagship client-side scripting language.
I find it hard to tell if this is ironic or not. Assuming it isn't, then it sounds like yet another 'let's jump on the supposed Ruby bandwagon' idea.
The true future of AJAX has to be based on components that hide as much of the client-side scripting as possible, and where Javascript-free alternatives can be automatically generated.
AJAX is surely only useful because all modern browsers have good JavaScript support bundled. Using another client-side language removes this advantage. If you are going to use another client-side language there is one that is proven and secure - Java.
|
|
|
Message #187930
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fourth forms of AJAX: band-aid.
I see Ajax as an attempt to cure syphilis with band aid. LOL! Could not agree more. Of all the available technologies, it seems like the community has chosen the one least suitable for the hype of the day.
And the examples given make me stare in disbelief. Combo boxes that go to the server (using encrypted modem connections probably) to obtain possible auto completions? Impressive stuff like Google Maps that is years behind the decent map24 applet in all interactive capabilities.
Given the current discussions re. IE 7, this comes back in a full circle to where you can only deploy your ajax application in a fully controlled environment, anyway. And when you do that there are much better ways to develop stable and long lasting applications.
|
|
|
Message #187932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
down with JavaScript
AJAX is surely only useful because all modern browsers have good JavaScript support bundled. Using another client-side language removes this advantage. If you are going to use another client-side language there is one that is proven and secure - Java.
The browser is at an evolutionary dead-end. That is the point of my proposal for the Web 2.0 client-side platform. My proposal does an end-run around the browser in order to advance Web 2.0 client-side technologies.
The AJAX daemon as a host for AJAX widgets (ala the Mac Tiger OS X Dashboard concept) is the "Trojan Horse" means to accomplish this. Oh, and the other side of this coin is to introduce an "iTunes" concept for AJAX Widgets so that a cottage industry for Widget making is established where consumers can buy a cool widget for a few bucks a pop.
Wouldn't it be great to be able to earn some green stuff again for one's inspired programming talents? Crafting a cool AJAX widget would be just the kind of endeavor to unleash the creative juices - and earning something back for such expended effort would be a very nice icing on the cake! The time is now ripe for this because a lot of prominent web sites are now offering SOA services that an AJAX Widget will be able to tap into to do all manner of inspired things.
So the AJAX daemon and the "iTunes" web site for AJAX widgets is a hand in glove concept. But it needs a seriously better runtime platform than the current web browser cul-de-sac. The AJAX Widget concept can't be truly unleashed until there is a daemon process to host it that is always there - just as the Mac OS X Dashboard process. And the richness of the standards the AJAX daemon provides to hosted Widgets needs to take a major leap forward beyond the anemic web browser and its myriad limitations.
The primary programming language for AJAX Widgets needs to be very productive and very easy to master. Ruby near perfectly fits this bill. It's an easy language to learn yet covers enough language turf such that it is a broadly capable language that can do some seriously powerful things. As a dynamic scripting language it's highly productive - which is precisely what is needed for the crafting of AJAX Widgets.
Web 2.0 will arrive when the web browser goes back to being relegated to hyperlinked pages that you read and navigate - while cool interactive programs (AJAX Widgets) are things you build for this new AJAX daemon runtime platform (which itself might be nothing but an installer that augments the existing browser install with the necessary Web 2.0 building blocks).
|
|
|
Message #187936
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fourth forms of AJAX: band-aid.
I see Ajax as an attempt to cure syphilis with band aid. LOL! Could not agree more. Of all the available technologies, it seems like the community has chosen the one least suitable for the hype of the day.
That's not necessarily the focus, IMHO, that should be pursued with AJAX in hopes of replacing the desktop at this point. We are still talking about the web pages. There's technology out there such as XUL which may be applicable, but where I see AJAX coming into play is in being able to immediately transition users without making a whole new request. The way that users interact with the web page shouldn't change-- click back button, click, back button-- it's the routine your grandmother can do. Put her in front of MS Word and she's gotta get a book our your ass over to show her how it works. AJAX can help bring that immediate responsiveness of a desktop to traditional web page interaction.
In summary, Java WebStart will always have its place along side Web Browsers, but for those delivering applications over the web, jumping over to Java WebStart may introduce complex functionality beyond the click/back interaction that people are used to on the web. If you want to find some middle ground in certain cases, then pursue AJAX lightly.
|
|
|
Message #187937
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
down with JavaScript
Wouldn't it be great to be able to earn some green stuff again for one's inspired programming talents?
Actually, I think not. Maybe I have been in IT too long, but I would rather stick with one clean language throughout to construct my apps. My experience is that real programming talent is used in software engineering, not re-writing everything in JavaScript and/or Ruby.
But it needs a seriously better runtime platform than the current web browser cul-de-sac.
But there are already better run time platforms - Java and .NET.
The AJAX Widget concept can't be truly unleashed until there is a daemon process to host it that is always there - just as the Mac OS X Dashboard process.
Like a JRE?
And the richness of the standards the AJAX daemon provides to hosted Widgets needs to take a major leap forward beyond the anemic web browser and its myriad limitations.
Something like Swing, perhaps?
The primary programming language for AJAX Widgets needs to be very productive and very easy to master. Ruby near perfectly fits this bill. It's an easy language to learn yet covers enough language turf such that it is a broadly capable language that can do some seriously powerful things. As a dynamic scripting language it's highly productive - which is precisely what is needed for the crafting of AJAX Widgets.
The same can be said for a large number of other established languages - Smalltalk, Scheme, Python etc.
I'm afraid the use of 'Ruby' here still sounds to me like jumping on a bandwagon. There are no advantages to it, in terms of usability, performance or security. Just Hype.
Web 2.0 will arrive when the web browser goes back to being relegated to hyperlinked pages that you read and navigate - while cool interactive programs (AJAX Widgets) are things you build for this new AJAX daemon runtime platform (which itself might be nothing but an installer that augments the existing browser install with the necessary Web 2.0 building blocks).
Sounds exactly like applets to me.
Also, your definition of 'Web 2.0' does not match what I seem to be able to find. From Wikipedia:
Web 2.0 .. "puts much greater emphasis on back-end software."
Also, Web 2.0 is "Purely web based - most successful web 2.0 sites can be used almost entirely through the browser".
So if you are doing an 'end-run around the browser', it's not Web 2.0.
I know it is sometimes fun to re-invent the wheel, but hardly good as a general strategy for IT progress.
|
|
|
Message #187945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fourth forms of AJAX: band-aid.
That's not necessarily the focus, IMHO, that should be pursued with AJAX in hopes of replacing the desktop at this point. We are still talking about the web pages. There's technology out there such as XUL which may be applicable, but where I see AJAX coming into play is in being able to immediately transition users without making a whole new request. I just came back from NoFluffJustStuff symposium (good one, highly recommend it by the way) where I have attended among others Ted Newadrd’s talk on “The Fallacies of Enterprise Computing”. There are those 10 fallacies:
1) The network is reliable
2) Latency is zero
3) Bandwidth is infinite
4) The network is secure
5) Topology doesn't change
6) There is one administrator
7) Transport cost is zero
8) The network is homogeneous
9) The system is monolithic
10) The system is finished
Lets just look at the Ajax with the fallacies in mind and lets especially consider items #1,2,3,4,and 7. It is not even funny…
|
|
|
Message #187954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
down with Ruby
Thank the Creator(s) of Ruby for creating yet another language that can save the world -- an marvelous missions attempted by Perl, Python, PHP, ...! But I have yet to find any trace of proof that Rube can rule the World.
|
|
|
Message #187957
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
Lets just look at the Ajax with the fallacies in mind and lets especially consider items #1,2,3,4,and 7. It is not even funny…
All the while iTunes is an immensely successful application that artfully uses web services and rakes in millions in revenue. Apple does the most skillful job of all of seamlessly integrating Internet web services into various aspects of their operating system features and their various applications.
And now they've introduced Dashboard which is a runtime expressly for hosting applets (widgets in their parlance) that are constructed out of HTML, DHTML, JavaScript, and AJAX style io. Dashboard Widgets are expressly designed to run in their own window and do all their own UI handling. They have nothing to do with the browser web page paradigm. They are declarative UI applets with procedural actions implemented via scripting language.
The reality of Mac OS X vividly illustrates that not only can all this be done successfully - well, gee - it already has been done. I think that is the point that shouldn't be missed here, folks. From a Macintosh user experience point of view, all these counter arguments and objections are without any substance. The last laugh goes to OS X users.
BTW, it would only be fair to mention to readers of this thread that this latest No Fluff Just Stuff symposium held in Seattle had numerous presenters and sessions that were all about Ruby and Ruby on Rails. Everywhere you turned - even in the presumably Java-centric sessions - conversation on Ruby (and Ruby as the next tipping point in software languages) would come up.
Dave Thomas had a great intro session on Ruby and followed with another excellent session that introduced Ruby on Rails (and this impression coming from a guy that usually detest all manner of server-side web development - give me rich clients and messaging-based SOA middle-tier). Even JSF guru, David Geary, presented a session on Ruby on Rails (the story on Geary is that's he's gone through an "Apostle Paul Road to Damascus" experience and has pretty much converted from JSF into the Ruby camp now). In Bruce Tate's session on Beyond Java, Ruby and Ruby on Rails definitely figured into the mix of that talk. Ben Galbraith had a great intro session and an advanced framework session for the AJAX client-side of the equation.
Okay, I did actually manage to go to one session where Ruby didn't get mentioned at all - the Enterprise Service Bus talk by Mark Richards. Java looks like it will still have a good bit of traction in that space. But if there were a JRuby container for my J2EE app server in which I could write my message driven beans in Ruby, I'd probably switch. These kind of languages are just more productive.
Yes, Java made great strides over C and C++. But it really is possible to be even more productive with dynamic typeless scripting languages - if they're good languages with sufficient expressive power. I've done many thousands of lines of perl for business production programming. It's great for getting a lot done in a hurry without all the tedium that goes with a Java programming approach. What I like about Ruby is that it has similar power to perl but cleans up practically every bad or annoying thing that I didn't like about perl - it also adds several features that go beyond perl 5. (Sorry Perl 6 - you guys are going to be way too late to the game to be relevant anymore.)
|
|
|
Message #187958
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
I really don't want to get into a RoR vs Java debate-- wait, yeah I do.
There's no reason why Java, with things like EJB 3 can't be just as productive as RoR. With RoR, you are tackling the problem from the DB layer, but with EJB 3, you are doing so from the Model layer via simple, or implicit annotations. You can run an ant script to take those annotations and create your DB if you want. Also, Christian (I think) from JBoss wrote a bit on generic DAOs with Hibernate that could apply to EJB 3 too.
I will give you that the main appeal of RoR is that there are lots of implicit capabilities-- which shorten development time. I've started to see some frameworks do this already. As a personal example, there's Facelets and then there's JSP-- JSP requires you to write lots of descriptor XMLs and Tags, where Facelets just implicitly auto wires everything to your objects.
As for AJAX, I think that the ideas used in RoR are old news. Stripes is able to do the same thing (actually any traditional MVC framework, just by using Prototype.js too :-)).
If anything, I believe Ruby and RoR will simply act as a benchmark for the Java community on how to ease development, we're already seeing it rapidly adapt to meet that standard.
|
|
|
Message #187959
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
. From a Macintosh user experience point of view, all these counter arguments and objections are without any substance. The last laugh goes to OS X users.
Being a Macintosh user half of the day, I can assure you that it is indeed very hard to find even a single decent usable valuable Dashboard Widget, bar "Dilbert of the day".
Let alone the responsiveness that you get from them. A weather widget, that takes minutes (without user feedback) to show you the weather. YAC (Yet another calculator), oh please....
iTunes, by and large, looks like a traditional Objective-C application to me and its main focus is to arrange play locally stored music (and movies) anyway, and not go and fetch stuff from the web (where its main revenue originates, but this is a different story). That it needs to go to the network to do this is hardly surprising and the actual protocol used to do that should be the least relevant question in designing the remote interaction.
|
|
|
Message #187964
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
With RoR, you are tackling the problem from the DB layer, but with EJB 3, you are doing so from the Model layer via simple, or implicit annotations.
I have had many amusing conversations with RoR people, that go something like this:
Them: "RoR is really fast for development."
Me: "But working from the DB layer is old-fashioned, restrictive, and leads to problems with portabibility"
Them: "Well, OK, this is a problem, but you don't have to use Rails. You can use alternative ORMs for Ruby"
Me: "So then it is not the magic much-hyped RoR, is it?"
Them: "Erm...."
Both JDO and EJB 3 work from the model layer, and I have seen plenty of tools (well at least for JDO - I am sure they are there for EJB 3 as well) that allow working from the DB layer as well, and keep code and schema synchronised. With these tools set up as ant tasks, so they are part of the build, then you have a persistence situation that can be as simple as Rails, but faster and more robust - they can update your code automatically. (Some of these tools have been around for far longer than Rails has been widely known).
If anything, I believe Ruby and RoR will simply act as a benchmark for the Java community on how to ease development, we're already seeing it rapidly adapt to meet that standard.
As long as it does not act as a benchmark for ease of development in the way that Visual Basic did - by allowing sloppy coders to get up quick-and-dirty fixes that lead to messy unportable code, tied in to one database. I fear that it will.
|
|
|
Message #187965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
But it really is possible to be even more productive with dynamic typeless scripting languages
This is a very old debate that has not come to a conclusion one way or the other over decades. Exactly the same arguments were being put forward in the Smalltalk vs C++ 'battle' as to the dominant OOP language in the 80s.
So, sorry for sounding cynical, but I just don't accept that dynamic typeless scripting languages are more productive generally. You have to describe the situation. For example, in the 80s C++ won out in general use because it allowed legacy code to be used and because it was 10x or more faster than Smalltalk, however Smalltalk was used (and still is) in many specialised areas. Specifying Ruby (and similar languages) as generally more productive is far too simplistic.
|
|
|
Message #187967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
Are there any servlet engines with AJAX implementations?
|
|
|
Message #187978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a compromise solution
Nice classification and I think modern web applications will use all three kinds for reaching better usabiltity. Yes, old standard web interface is too complicated for users and we have to find a way for making their life easier that they wouldn'f fill less comfortable using web interface than standard GUI. I think we're close to it as never before, look at for example http://itodo.mawisoft.com
|
|
|
Message #187981
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a compromise solution
Yes, old standard web interface is too complicated for users and we have to find a way for making their life easier that they wouldn'f fill less comfortable using web interface than standard GUI.
I certainly don't agree that the standard web interface is too complicated for users. On the contrary, I have found that users have a general opinion that the web is 'friendly' and they will use all sorts of controls and features on a web page that they would hesitate to use in a standard GUI.
The issue is that the standard old web interface is too complicated for developers.
|
|
|
Message #187987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
You have to describe the situation. For example, in the 80s C++ won out in general use because it allowed legacy code to be used and because it was 10x or more faster than Smalltalk, however Smalltalk was used (and still is) in many specialised areas. Specifying Ruby (and similar languages) as generally more productive is far too simplistic.
Agreed. And don't forget it depends on how you use a language. For example Java is more and more forced into usage as an actually untyped language where we pass objects around - preferably using a messaging mechanism - or where generic methods like "doSomething" are defined way up in the type hiearchy :-).
I am currently waiting for the next wave of "Unsafe languages leads to more stable software" debate :-)
|
|
|
Message #187997
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web 2.0
Lets just look at the Ajax with the fallacies in mind and lets especially consider items #1,2,3,4,and 7. It is not even funny… ….
And now they've introduced Dashboard which is a runtime expressly for hosting applets (widgets in their parlance) that are constructed out of HTML, DHTML, JavaScript, and AJAX style io. Dashboard Widgets are expressly designed to run in their own window and do all their own UI handling.
I am with Karl, the Dashbord and those supposedly cool widgets clearly demonstrate fallacies
#1- The Network is reliable;
and #2 – Latency is zero;
the net result – I do not use the dashboard because it takes ‘forever’ (subjectively) for those widgets to display information they are supposed to display.
Dave Thomas had a great intro session on Ruby and followed with another excellent session that introduced Ruby on Rails (and this impression coming from a guy that usually detest all manner of server-side web development - give me rich clients and messaging-based SOA middle-tier). Hmm, with all my respect to Dave I consider the session to be really bad, might be because it supposed to be “Ruby for Java programmers” but instead it was “Introduction to Ruby”
Even JSF guru, David Geary, presented a session on Ruby on Rails (the story on Geary is that's he's gone through an "Apostle Paul Road to Damascus" experience and has pretty much converted from JSF into the Ruby camp now).
IMO it is no-brainer to switch from JSF, or Struts, or PHP to RoR, however I still convinced that RoR fall far short in comparison with
DreamWeaver + Tapestry+ (Spring|HiveMind)+ Hibernate+ (Eclise+Spindle|IntellijIDEA) combo.
One thing that RoR apostles do admit: today RoR does not support i18n therefore limited to single language sites only.
|
|
|
Message #188009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
languages languages
But it really is possible to be even more productive with dynamic typeless scripting languages This is a very old debate that has not come to a conclusion one way or the other over decades. …. but I just don't accept that dynamic typeless scripting languages are more productive generally. ….
Specifying Ruby (and similar languages) as generally more productive is far too simplistic.
+1
May I bring to the attention of the forum that there is coming another wave. The wave is the reincarnation of the idea of Domain Specific Languages (DSL). It was around for many decades but nowadays it seems to gaining necessary attributes for success. One think that I think enables that is the ability to navigate code and ability to see contextual help and validation. One tool that enables it is the MPS from JetBrain (http://www.jetbrains.com/mps/index.html )
There was Neal Ford’s presentation on DSL at the NFJS and I am with him on this: it is going to be huge. (http://www.nofluffjuststuff.com/show_session_view.jsp?sessionId=1203&showId=30 ) I think that the DSL wave will swallow scripting languages as well as MDA.
|
|
|
Message #188011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX security
I never got heavily into Javascript tricks, but if we have a heavy AJAX-based app, that means that the app code is exposed when it is shipped to the browser, is it not?
I suppose you could try to do some stuff like download the code in strings and then do a parse of the thing, so that the code isn't exposed, but that seems ugly.
From a consumer standpoint apps like these can submit monitoring information without your approval or knowledge. At least with the old click system you could choose not to submit a form. Is it possible to kick off an ajax app in a hidden window and monitor what other sites a person surfs?
Hopefully AJAX prompts a thorough rework of client-side processing that fixes cross-browser compatibility, provides a better language choice than ECMA, and make advanced UI development easier than a haphazard mix of CSS and JS, but I doubt MS would play nice with KDE/Firefox/Opera.
|
|
|
Message #188031
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
You know what...it is called XWindows :) LOL, this will hopefully eat up less processor ;-)
Less processor... AJAX... XML... Isn't some kind of paradox there ???
:-)
Have fun,
Remi - anybody heard about a Ruby-scriptable VNC ???
|
|
|
Message #188035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Three forms of AJAX: solid, liquid and gas.
Are there any servlet engines with AJAX implementations?
Yes, all of them.
|
|
|
Message #188047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
You know what...it is called XWindows :) LOL, this will hopefully eat up less processor ;-)
Less processor... AJAX... XML... Isn't some kind of paradox there ???:-)
Have fun,Remi - anybody heard about a Ruby-scriptable VNC ???
Think of it this way, the ideas I'm proposing involve stateless end points (much like REST), but deliver only gui changes back to the browser-- so I could deliver just 85 bytes of data back over the network, where something like a windows/vnc screen scraper may deliver a lot more data since it doesn't have the luxury of a client side rendering facility. So yes, boo and haw at XML, but from experience with HTML, putting <span>Some Text</span> is a lot less information to transport than a rendered image-- why do you think SVG is picking up steam?
-- Jacob
|
|
|
Message #188051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
Think of it this way, the ideas I'm proposing involve stateless end points (much like REST), but deliver only gui changes back to the browser- +1 for delivering changes only ( that is the core idea of XWindows/ VNC by the way);
-1 for the idea of stateless interfaces;
Stateless services are not always better and faster. In many cases it is cheaper to keep the state than to recreate it every time a request comes.
|
|
|
Message #188057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
Think of it this way, the ideas I'm proposing involve stateless end points (much like REST), but deliver only gui changes back to the browser-
+1 for delivering changes only ( that is the core idea of XWindows/ VNC by the way);
-1 for the idea of stateless interfaces;Stateless services are not always better and faster.
In many cases it is cheaper to keep the state than to recreate it every time a request comes.
That's totally true, but I believe that stateful services are the minority (the 80/20) case, so yes, they are very important, but the solution shouldn't force the whole view architecture to be stateful in the process.
|
|
|
Message #188073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
That's totally true, but I believe that stateful services are the minority (the 80/20) case, so yes, they are very important, but the solution shouldn't force the whole view architecture to be stateful in the process. Absolutely!
Infrastructure simply should fully support stefulness if/when developers/architects need it.
|
|
|
Message #188221
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
Was just kidding, of course XWin is expensive, but try using a VR application through a web browser even using AJAX... :-)
They're different things for different purposes. X-Win is one of the most "primitive" type of client/server applications (terminal). No one even though about using it for a high-traffic application like a web site.
If I get it, what you propose looks more like regular "fat" client (you know, getting data from somewhere and presenting it to the user) without the burden of deployment (well, JavaScript etc won't help there IMHO it's just moving the problem somewhere else).
I get it : it's Laszlo without Flash :-)
Honestly, no offense it's just my personnal opinion, but I can't see the point in trying to do complicated things in the browser in ASCII mode over HTTP whereas using other technologies would be so much easy and quick...
IMHO WebStart is a very good example of how you can build user-friendly clients with virtually no limitations and much simpler than struggling with the usual webapp stack.
But that's an already too much debated subject...
My $0.02
Have fun
Remi
|
|
|
Message #188238
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XWin
If I get it, what you propose looks more like regular "fat" client (you know, getting data from somewhere and presenting it to the user) without the burden of deployment.
No, not really... it looks and is a web page, works the same as every other framework, except that content is refreshable in select instances. I'm in the same boat as you on this.
It doesn't do us much good to spend tons of time trying to use AJAX as an alternative to fat/swing clients-- only to enhance the experience of interacting with a 'web page' in limited fashion.
|
|
|
Message #188249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's wrong with JavaScript?
What's wrong with JavaScript? Its been made into a standard language, and its widely supported. There's even a 100% pure Java implementation of a JavaScript engine called Rhino.
JavaScript is object oriented, and uses prototype-based inheritence. The specification is simple enough to read in a single sitting, but still powerful enough to accomplish just about anything.
So, again, what's wrong with that?
|
|
|
Message #188256
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's wrong with JavaScript?
What's wrong with JavaScript? Its been made into a standard language, and its widely supported. There's even a 100% pure Java implementation of a JavaScript engine called Rhino. JavaScript is object oriented, and uses prototype-based inheritence. The specification is simple enough to read in a single sitting, but still powerful enough to accomplish just about anything.So, again, what's wrong with that?
JavaScript's one virtue as a scripting language is that it is not VBScript. It has very few powerful idioms or mechanims in the language to support such, and the breadth of standard class library is pathetic. Other scripting languages, such as Perl, have a great number of highly expressive idioms and language features that facilitate such and a vast range of libraries. Ruby is of a caliber of scripting language in terms of its expressive power coupled to language features to be in that league. It has a very significant and capable standard class libraries defined for it (want to do some socket stuff - go ahead).
When you have a truly powerful scripting language, AJAX apps on the client-side can be take to a whole new tier of sophistication. The fundamental problem of the Mac Tiger OS X Dashboard for Widgets is that the language for Widget implementation on the procedural side of things is JavaScript. The Dashboard certainly needs more powerful declarative capabilities (XUL, SVG, etc), but most definitely it needs a truly powerful language to program all that with - Ruby. This is the linchpin in my plan for implementing what would be a true Web 2.0 client-side runtime platform:
When AJAX will truly be worthy of "Web 2.0" moniker
http://www.javalobby.org/java/forums/m91937075.html
We don't need a scripting language that makes it possible for five years olds to script a web page. Instead we need a powerfully expressive language that can truly redefine the Internet web experience into something worthy of being dubbed Web 2.0. We need to dump JavaScript now and move to Ruby. My "Trojan Horse" plan for getting to true Web 2.0 is the means to accomplish such a transition.
|
|
|
Message #188268
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
I'm working on one such framework right now that is meant to work with existing MVC frameworks. Jacob, what kind of monster are you developing? Tell us more, please.
|
|
|
Message #188275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
it's still being fleshed out, but it works similarly to the ajax jsp tags that someone linked here, but will be using it's own document compiler (probably the same kind as I wrote for JSF Facelets) so your regular HTML is all part of the document such that you could say, refresh the element with div id="foo". It's not an attempt at a full blown MVC framework or compete with JSF or Tapestry, it's just a view technology that will offer 'callback' functionality and remove the need to mess with AJAX/JS yourself in the process. Very simple, very fast.
Again, it follows the mindset that 90% of the time, you just want to render a page, BUT, if you do want to page through a table or refresh some div on the fly or immediately submit a form value, you can without any headaches and complex javascript.
|
|
|
Message #188288
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
Sounds familiar. I'm not sure it you have noticed my previous comment #187962. Anyway, this is an important direction to follow.
|
|
|
Message #188298
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
if you don't mind me asking, if you are using JSP, doesn't the whole page get buffered, and then you only send back the block that you've defined as refreshable?
With running into a new parser, that accomodates treating anything as refreshable, without JSP tags, it does allow me to dive in and only render the block that you've specified to refresh-- not needing to output/buffer the whole page for pruning. Maybe the ajax tag solution you guys have come up with works differently?
|
|
|
Message #188303
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dynamic clients revamped
It doesn't do us much good to spend tons of time trying to use AJAX as an alternative to fat/swing clients--
Agreed. Moreover you loose the web designers most of the time (most of the ones I personnally know still use PShop and Dream 99% of their time and they rarely are experts in XML & Javascript)...
only to enhance the experience of interacting with a 'web page' in limited fashion.
Well, if I remember well, that's precisely why JavaScript was invented many years ago ! ya know, client side validation, animated widgets...
Simply put a little bit of XML in there, shake, and serve hot : you have an over-hyped stuff for nothing and you can expect hundreds of managers to love the taste and invest money to buy your receipe. I suspect digestion will be harder ;-)
As you say, all this is worth being explored, but it does not deserve such a buzz IMHO. One good thing though : with all that work they may finally agree on JavaScript's "compatibility issues", and web developers may expect their stuff to run the same way on all browsers / platforms some day !
Have fun,
Remi
|
|
|
Message #188318
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dynamic clients revamped
Simply put a little bit of XML in there, shake, and serve hot : you have an over-hyped stuff for nothing and you can expect hundreds of managers to love the taste and invest money to buy your receipe. I suspect digestion will be harder ;-)As you say, all this is worth being explored, but it does not deserve such a buzz IMHO.
Slightly overstated, but yes. Things like Google Suggest or Google Maps are better than what was attempted in the past. The solutions are simple, don't really change the web semantics, and increase the user experience. That's all developers should gun for with JavaScript and AJAX.
Stuff like BackBase or other full JavaScript frameworks may take off, but they don't hold a flame to what can be done with WebStart or alternative technologies like Laszlo or Flex.
-- Jacob
|
|
|
Message #188351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX security
I never got heavily into Javascript tricks, but if we have a heavy AJAX-based app, that means that the app code is exposed when it is shipped to the browser, is it not?
People can argue this both ways. We have always had the conversations of can I stop view source. JavaScript, images, html, css, etc have always been open. I always say, JavaScript is open source, you can try to make it hard to read, but no matter what you do, it can be figured out.
With this said the business logic needs to sit on the server. It should not be controlled with JavaScript. With that said it makes it a little bit more secure. You need to follow the same rules for a normal form submission. Check the data before you do anything!!
I suppose you could try to do some stuff like download the code in strings and then do a parse of the thing, so that the code isn't exposed, but that seems ugly.
With just using the location bar anyone that has JavaScript knowledge can destroy the data that comes from a form. Plus the decoding logic has to be sent along so you are just putting the key under the front door mat.
From a consumer standpoint apps like these can submit monitoring information without your approval or knowledge.
At least with the old click system you could choose not to submit a form.
Hidden iframe with a textbox and javascript timer can send data back. Heck that is how people used to do "Ajax" coding before they realize MS had the XMLHttpRequest Object.
Is it possible to kick off an ajax app in a hidden window and monitor what other sites a person surfs?
I think you need to read about browser security! One domain can not read information from another domain without the users permission. So no you can not monitor another site. The XMLHttp Request object can work across different domains too!
Hopefully AJAX prompts a thorough rework of client-side processing that fixes cross-browser compatibility, provides a better language choice than ECMA, and make advanced UI development easier than a haphazard mix of CSS and JS, but I doubt MS would play nice with KDE/Firefox/Opera.
The reason why people will not embrace Ajax is the fear that has been drilled into them or their laziness to get off their butts and learn a new language.
Yes there are cross browser problems, but if you code correctly and vist sites like quirksmode, it should ease the problems. Get a good JavaScript Book are use it!
And the laziness part is true. Some developers out there do not want to change the way they have been coding for X number of years. They still refuse to use CSS and can not match the stands for HTML 4.01. I have seen, worked with, contracted for, and dealt with them.
When I do consulting work I always say to the client:
Ajax is not meant to change the way a web app works, it is meant to enhance it.
My 2 cents,
Eric Pascarello
|
|
|
Message #188362
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
if you don't mind me asking, if you are using JSP, doesn't the whole page get buffered, and then you only send back the block that you've defined as refreshable? The whole page does not need to get buffered. It’s not implemented yet, but the concept allows buffering only the zones to refresh. However, the whole JSP is evaluated and rendered.
I don't think this overhead will discourage project management, especially if we upgrade existing app, which already renders the whole page for every post-back.
With running into a new parser, that accomodates treating anything as refreshable, without JSP tags, it does allow me to dive in and only render the block that you've specified to refresh-- not needing to output/buffer the whole page for pruning.
I thought, the easiest way to specify frontiers of a block is to use JSP Tags. Otherwise, the application would need to list the IDs of all tags to update.
Another option I see it to determine changes by comparing buffered JSP output with its previous content.
What is your option ?
Maybe the ajax tag solution you guys have come up with works differently? Yes, Ajax Tags have recently picked up the idea of updatable HTML areas. At least it means that the concept is not that bad ;)
It would be interesting to hear their opinion.
|
|
|
Message #188367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
framework that is meant to work with existing MVC
I thought, the easiest way to specify frontiers of a block is to use JSP Tags. Otherwise, the application would need to list the IDs of all tags to update. Another option I see it to determine changes by comparing buffered JSP output with its previous content.What is your option ?
Knowing all of the ids would be a luxury of a new document parser, such that without evaluating each tag, you could, given a client-id, reach into the document and pull out a renderable context-- or block. It does require a more declarative approach to UI design, but you are right, what you guys have is better than simply sending the whole page.
I keep on going back to the case (within JSF/components) that to render a single row of a table, you have to re-render all rows and all other content-- re-fetch it model information for everything and require that all components/concerns on the page are enabled for use, where isolating a single row/id, you wouldn't have to re-iterate over all data and just setup context for that one row and render.
Also, by going stateless with components in this fashion, it does offer opportunity for components to turn around and basically render links back to themselves-- by ID, such that a 'charting' component could deliver binary images back to the client without going re-rendering everything on the screen in the process that you don't care about.
Like I said, I'm still running through ideas, but it would be a real push away from JSP's execution model-- which has its pro's and con's.
|
|
|
Message #188435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
buffering "zones" in the screen : layers ?
Maybe I did not understand anything to this 'page zone refresh' stuff, but can't you use layers to do this ?
I mean, use *async* AJAX to get the layer contents (e.g. from another JSP), and hide previous layer / show new layer when data is obtained ?
I've seen this for tabbed-panes style UI in a R&D project I'm in. I was not in the "UI team" but a guy there told me ha was using mainly IFRAMEs and layers to achieve 'page zone refresh'...
Maybe a taglib could generate necessary client-side stuff (HTML/JS) for you, like :
<code>
<ajax-tpane:pane>
<ajax-tpane:tab title="1st tab" content="./Tab1.jsp"/>
<ajax-tpane:tab title="2nd tab" content="./Tab2.jsp"/>
<ajax-tpane:tab title="3rd tab" content="./Tab3.jsp"/>
</ajax-tpane>
</code>
Are the tags you talk about more or less looking like this ?
Have fun,
Remi
|
|
|
Message #188438
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
buffering "zones" in the screen : layers ?
Maybe I did not understand anything to this 'page zone refresh' stuff, but can't you use layers to do this ?I mean, use *async* AJAX to get the layer contents (e.g. from another JSP), and hide previous layer / show new layer when data is obtained ?
Are the tags you talk about more or less looking like this?
Have fun,Remi
Yeah, without any special framework, you've always been able to do that with AJAX-- see any of the stuff from Ruby on Rail's use of the Script.acul.us and Prototype libraries. Where the desired behavior lies though is expression all of the content within a single document instead of breaking it up into multiple pages such that all components/content contained share the same scope/lifecycle.
-- Jacob
|
|
|
Message #188779
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JavsScript is not the DOM
You mention the core libraries, and some might argue whether that's part of a language. I'll give you that it is, and that means JavaScript's core is quiite small (about a dozen objects, if I recall correctly). But when you use it in different ocntexts, that library is augmented. Use it in a browser and you have the DOM. Use it in Windows Scripting Host and you have a huge Windows API at your finger tips. Use it inside your Java program, and you can expose anything you want to it.
But you also go on to tlak about JavaScript being limited to eb used by children to make web pages. On the contrary, I've used JavaScript not just in web pages, but also in system administrator scripts, Laszlo, cusotmization engines in enterprise solutions, etc. If you're thiking of JavaScript as the thing ou use with DHTML, then you're only scratching the surface. Go look at things like Rhino that let you embed a scirpting engine in any Java program.
Now you also go on to talk abotu the poor feature set of the language itself. I assume you mean the base syntax and constructs. The language is evolving to support classes, but as it stands now, the prototype-based inheritence has been fine for my purposes. What other languages is that Ruby has that makes it all powerful?
I'm apprehensive of saying that some new language will solve all of our problems when I've not seen anyone point out why an wifely proliferated, accepted standard can't.
|
|
|
Message #189123
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Author Has It Right
Like the author of the article (Vitaliy Shevchuk) notes, each of the 3 forms has their ups & downs. While both component-oriented and sub-page oriented approaches (AjaxAnywhere, DWR or AjaxTags) are a nice way to abstract the details of using Ajax for a large percentage of it's use, you simply cannot componentize everything.
The #1 approach (Application-specific JavaScript) is not "model 1" -- it's simply a customized solution. It could be model 1 if someone doesn't know JavaScript well or simply isn't a very well organized programmer.
If we're honest, we'll realize that approaches 2 & 3 are cookie cutter approaches that may cover a large percentage of potential Ajax usage, but are only the tip of the iceberg of Ajax possibilities.
Just like we often need a custom solution with our Java code, there will often be a user interface requirement that forces us to think outside the box and create a custom solution. Approaches 2 & 3 will only ever get you so far.
Ajax is only beginning to revolutionize the way web applications are being built. Like it or not, JavaScript is an important part of the infrastructure of this new approach and knowledge of it will become increasingly important for us.
|
|
|
Message #204820
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax
can u send me the workflow of ajax and how to run ajax clear way please show me the simple code and procedure to run that code
okay
bye
|
|
|
Message #252163
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Fourth form of Ajax - Visual
The classifications you gave for Ajax are right as far as they go. Where Ajax gets interesting is when we get back to visual tools for doing visual development. Think PowerBuilder for Ajax.
Using coding tools to build increasingly interactive user interfaces is like using hammers to screw in lightbulbs!
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
