|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 27
Messages: 27
Messages: 27
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Article from java.net: Developing AJAX Applications the Easy Way
Joe Walker has a new article on java.net, called "Developing AJAX Applications the Easy Way," that uses DWR to create a multi-user web-based chat site in about 100 lines of code for both the client and the server.
The article doesn't create a secure chat of any kind, but it does illustrate how easy AJAX can make development. This application isn't large enough to truly benefit from AJAX (except as an example application), and apparently requires the user to send messages to receive messages - perhaps Mr. Walker will add an asynchronous polling mechanism to the example to show us live updates, normally a requirement for people who lurk on such chats.
What do you think? Is the example worthwhile?
|
|
|
Message #182620
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DWR works for me
I'm exploring DWR myself and I'm very impressed.
The article does not show a finished application. There are a bunch of "improvements" that could be added to the article's application. I would judge it on another level: does it show how async communications can make a web application better.
I think it passes that test. The example is worthwhile because it will give reads food for thought.
|
|
|
Message #182621
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
The live site does have the asynch update functions. They were missed out of the tutorial because the tutorial was just about getting running with DWR.
Ajax Pitfall to watch out for:
If you write an Ajax site with a URL like http://getahead.ltd.uk and then some (like for example java.net) links to it using http://www.getahead.ltd.uk you could get an error from the XHR component. In this case a little apache-foo was all that was required to fix it, but it is one worth watching for.
|
|
|
Message #182624
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
Does Echo have an integration with Spring ?
One of the feature that I like in DWR it's the easy way to export beans defined in the spring factory just by adding a simple XML definition.So,no code is required on the server side.
FYI..I have created a demo with DWR and Spring so my comments may be biased. ;-)
http://claudehussenet.com
Rgds.
|
|
|
Message #182629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
I heard, AjaxTags (http://ajaxtags.sourceforge.net) was easier to use.
o Rico and Ruby on Rails have a library.
o Sajax
o WebORB from wwww.themidnightcoders.com
o BEA may have big support for AJAX early 2006
o Don't forget, even Apache Cocoon can work similar.
o Isomorphomic (What's your experience?)
o Backbase (http://www.backbase.com) (What's your experience?)
o TIBCO General Interface
o XTT from InsiTech (thin but smart Swing client)
What is your experience with any or all of these, by the way? If you have some experience, do you like open-source AJAX technologies or commercial vendors? I will let you know what I find though.
Can you share your experience and let us all know? Note that the term 'AJAX' was coined by Adaptive Path before "AJAX" took off.
|
|
|
Message #182633
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
I heard, AjaxTags (http://ajaxtags.sourceforge.net) was easier to use.
What is your own experience with this tag librairie ?
Just by looking at the first sample from the link provided,it seems that the xml generation on the server side is left to the developer !
With DWR,u just specify the following line in a DWR config file
<create creator="spring" javascript="portletContainerService">
<param name="beanName" value="portletContainerService"/>
</create>
and u're done !
Rgds-Claude
|
|
|
Message #182643
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
I've run into Scriptaculous (http://script.aculo.us/), which have some amazing AJAX components. Some people are already working on integration with Wicket framework, which would take the meaning of "best of both worlds" to a whole new level ;)
|
|
|
Message #182645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Using DWR and lovin' it
I've been using DWR for a few weeks on my own pet project (http://tudu.sf.net).
It's working great for most of my AJAXian needs - publishing Spring beans in Javascript is super-easy. Of course, I sometimes have other needs (publishing a whole JSP as an inner HTML component) where DWR is not enough, but for that I don't need a framework to help me.
Anyway, some interesting facts :
- DWR works perfectly with Acegi security, in case you're frigthened about the security of your Spring beans
- DWR is _really_ publishing your Spring beans : I currently have a tiny bug where my Spring's ObjectRetrievalFailureException goes all the way throught my app's layers to the JavaScript, showing it as a JavaScript error!
If you want to try out my project, it's full of DWR examples : http://tudu.sf.net
|
|
|
Message #182646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX communication vs AJAX RIAs
...
o Isomorphomic (What's your experience?)
...
Correction: Isomorphic
Our experience: The SmartClient AJAX presentation layer has been deployed in global production extranets since 2000, generally available as a developer product since 2001, and licensed by leading ISVs (including PeopleSoft, Oracle, and at least two of the companies mentioned in TSS headlines this week) since 2002.
If I can make an observation -- The world of AJAX projects and products currently breaks down along two lines:
1) AJAX communication libraries
Most of the emerging projects are simple wrappers of XMLHTTP, to enable some backchannel browser-server communication. This is a quick way to enhance certain interactions (like background loading of SELECT values) in existing web apps. It is fairly easy to "roll your own" background comm with XMLHTTP, albeit with limitations including dependence on ActiveX in IE, no push capability, no file uploads... There are several other "AJAX transports" to solve these issues, including IFRAME approaches, but they are much more difficult to implement and debug on your own.
2) AJAX RIA systems
A handful of products, all commercial, are building or have built sophisticated GUI frameworks on top of one or more web browsers, using asynchronous JavaScript techniques to render HTML/CSS on the client. SmartClient, Backbase, and General Interface are all in this space. An AJAX communication library is usually a very small part (like 1% of the public APIs) of these systems. The heavy lifting is in the vast array of workarounds and patches for in-browser rendering and interactivity.
If you are considering "AJAX enhancements", it is important to make this distinction: Do you want to add some background requests to your applications, or do you want to provide rich GUIs in the web browser?
Hope this helps-
Jeff Dill
Isomorphic Software
www.smartclient.com
|
|
|
Message #182657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WebORB vs Isomorphic
Jeff,
You should forgive me for the typo that I had earlier with Isomorphic.
In the commercial world, how do you compete with WebORB from http://www.themidnightcoders.com?
I see that WebORB Pro is $799 whereas WebORB standard is free. Your SmartClient is $5K/CPU from the licensing page.
If you justify and compare, you will help us as AJAX developers.
|
|
|
Message #182690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WebORB vs Isomorphic
In the commercial world, how do you compete with WebORB
Short answer - these are not competing products. WebORB is a communication layer and request broker; SmartClient is an AJAX RIA platform. The distinction will be clear if you explore the live examples on our respective websites. Feel free to contact me via the website if you would like to continue this discussion off-forum.
Jeff Dill
Isomorphic Software
www.smartclient.com
|
|
|
Message #182699
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Will AJAX drive adoption of component frameworks?
Having worked now with two AJAX libraries as well as multiple model 1 and model 2 frameworks in several languages, I think AJAX is going to change the playing field pretty dramatically for webapp frameworks. The 'natural' way of developing an AJAX application in a model 2 environment (I'm not even going to mention model 1) is to have a fairly thin JS<->Servlet transformation layer which is solving many of the same problems that XML-RPC solves, and then hook up JavaScript handlers and Java-side event handlers to do the 'application logic.' This is how DWR works, just to connect my comment here to the actual context I'm putting it in. ;)
The problem here is that the 'application logic' on the JavaScript side is fairly laborious and not really part of the standard skillset of your typical Struts or JSP developer, unless perhaps they come from the client scripting / DOM world. Even then you're dealing with an error prone, hard to debug, cross-platform nightmare compared to the Java side of the equation. As someone just getting into AJAX, my immediate reaction was "Christ, can't I just focus on what I'm good at and what I care about here without having to learn all this JavaScript stuff which isn't really core to my app anyway?"
Enter component-driven frameworks like JSF and Tapestry.
It seems to me that these frameworks are ideal for developing AJAX-enabled dynamic components on your web page. The components can generate all of the client-side layer up to and including the JavaScript glue that is such a pain to write if you don't come from that world. Suddenly the event handling model is more than just a convenient mental conceit that makes your webapp easier to write, it's actually how things work! How much more natural will it be to write dynamic event handlers when the events are actually dynamic? (Obvious answer: a lot.)
IMO all the AJAX libraries, including DWR, which are designed from the ground up in the Model 2 world seem impedance mismatched with the underlying methodology. Component frameworks, which up until I started writing AJAX code seemed to me to be just another unnecessary abstraction layer, is now where the action is. I can't wait to see what great AJAX stuff comes out of the Tapestry or JSF community. I'm betting it'll make life a lot easier for those of us who want to focus on writing code that matters vs glue logic that's forced on us by the libraries we're using.
|
|
|
Message #182702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is DWR open source?
What about licensing?. Can I use it in commercial projectsas is? From its home page: DWR is freely available as open source software (ASL version 2.0). It is straightforward to implement with extensive libraries, examples and tutorials.
|
|
|
Message #182713
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Will AJAX drive adoption of component frameworks?
Absolutely. AJAX enables rich GUIs, and rich GUIs are inherently component-based.
In the short term, server-side view-component frameworks like Tapestry and JSF should see a bump in adoption, because they are the shortest route to components for server-side developers.
But rich GUI components run on the client, so they will require a client-side framework regardless.
Now when you combine a client-side AJAX GUI framework and components (eg SmartClient) with a server-side view-component framework (eg JSF), you essentially have the old ASP.NET web controls architecture. You get richer UI, but managing the individual view components on ~both~ client and server impacts scalability and responsiveness, and tightly couples your client and server technologies.
The solution is to manage this level of view componentry on the client ~only~. Client and server then communicate in terms of authorized data models and operations, not user interface events.
At their core, this is what the various RIA platforms are about: Client-side MVC, with a shared client-server Model. But this will not happen overnight, and especially not on TSS. ;)
Oliver Steele of Laszlo (the open-source Flash RIA platform) wrote an excellent article (http://osteele.com/archives/2004/08/web-mvc) about this progression last year, with lots of diagrams. Check it out if you're interested.
Jeff Dill
Isomorphic Software
http://www.smartclient.com
|
|
|
Message #182818
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice article, but...
So, that's a nice article, but it's inaccurate about the eventual RIA diagram. In fact they look exactly the same in the end, it's just that the RIA app has thicker view and controller layers on the client side. However, despite the diagram, these thicker layers don't obviate the need for server-side controller and view layers, because you still have to be able to do things like fetch the next 20 topics in a forum. Really, anything else that requires more state than the client can reasonably be expected to download and maintain will in turn mean a server side which contains more layers than just a bare Model. For instance, do you really trust the client to do validation, auth, or transaction control? Obviously you will revalidate data on the server even though the client did some of it for you, and you're not going to put auth and transactions directly into your model for equally obvious reasons. Perhaps AOP goes some of the way towards streamlining this, but I think it's a stretch to say you could do away with your View/Controller layers on the server altogether.
So in the end the author has painted himself into kind of a corner, diagram-wise anyway, and produced two diagrams that (should) look exactly the same. Since it seems like his intent is to demonstrate that RIA's aren't more complex to develop than server-side MVC apps, perhaps he'd be ok with this. However, I have to take issue with this hypothesis as well, because as I said the client-side MVC layer in his diagram is far thicker in the RIA than it is in the server-side MVC app. That's the whole point after all.
What he seems to completely sidestep is that you're not developing them in the same language or for the same environment. I'm not 100% sure about .Net, but obviously anything where you could download a .Net component and just run it locally would fall under ActiveX and therefore be most comparable to a Java applet. And most people don't consider either Java applets or ActiveX controls to be a part of the whole zero-download web application space. Therefore all the major web development methodologies would require you to master at least two languages and their associated frameworks -- your server environment and the client's JavaScript environment.
It's non-trivial to find a developer who is equally skilled in both environments. If you're fortunate enough to have a skilled JavaScript person available whenever you need them and the costs of working with them aren't too high (both explicit and implicit costs of course), then perhaps this isn't a big barrier. For many people this is obviously not the case.
So, back to my original point, it seems like there is going to be a premium placed on frameworks which allow a developer to focus on the business logic, and to implement this business logic completely in their chosen environment without having to worry about JavaScript, the DOM, cross-platform concerns, etc. Looking at the Isomorphic website, I'm preaching the choir here. Where we may differ is in our expectations of the impact open source will have on this area. I think we can both agree that 90%+ of the web applications developed in the world are going to be running on 'Free As In Beer' platforms, however, and so a commercial solution to this problem has limited scope of impact regardless of anything else.
This is why I'm looking to the open source world to do something interesting here. Of course Microsoft could do it as well, with .Net. My guess is that they're not going to be particularly motivated to further narrow the gap between the user experience for web apps and client apps, at least not without locking the user into Internet Explorer and .Net. So waiting for something from them that solves this problem might be akin to waiting for Godot.
|
|
|
Message #182851
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice article, but...
So, that's a nice article, but it's inaccurate about the eventual RIA diagram. In fact they look exactly the same in the end, it's just that the RIA app has thicker view and controller layers on the client side...
...AND the server side has much thinner view and controller layers.
So thin, in fact, that Oliver was justified to drop them in those diagrams. There are remarkably few functions left for these layers to perform in most web applications. Data fetching, auth, validation, and transaction control are actually operations and rules on the model, not the view.
So, back to my original point, it seems like there is going to be a premium placed on frameworks which allow a developer to focus on the business logic, and to implement this business logic completely in their chosen environment without having to worry about JavaScript, the DOM, cross-platform concerns, etc.
Exactly.
Where we may differ is in our expectations of the impact open source will have on this area. I think we can both agree that 90%+ of the web applications developed in the world are going to be running on 'Free As In Beer' platforms...This is why I'm looking to the open source world to do something interesting here.
Yes, open source could be the new end of the line for all mature platform software. But as a rule, open source projects do not innovate--they copy stable solutions. It takes 5-10 years for a new software product category to mature to the point where comparable open source projects can emerge. Not everyone can wait that long...
|
|
|
Message #182865
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Feedback on InsiTech's XTT
This is in reference to the request for info on XTT and other frameworks. I've been working with XTT for about 6 months now and it is extremely powerful and easy because it's just Java. You only need to work with one language and can put as much or as little code in the client as you want. InsiTech provides development wizards that make it easy to develop rich, robust apps quickly.
While Java is becoming more common on end user's machines, it is not yet ubiquitous, and can therefore be problematic for public access applications. For this reason, XTT is an excellent choice for corporate or ASP applications for which the need to download a small amount of code is not an issue.
|
|
|
Message #182881
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice article, but...
There are remarkably few functions left for these layers to perform in most web applications. Data fetching, auth, validation, and transaction control are actually operations and rules on the model, not the view.
Your model objects are going to look awfully non-modelly with all that code inside them. Maybe that's not what you meant, but the code has to go somewhere, and I'd put it in a controller if nothing else. I can buy the View going away, if you send me $1, maybe. ;) (You'll still need some kind of resolver piece btw, which some people might call a View.)
But as a rule, open source projects do not innovate--they copy stable solutions. It takes 5-10 years for a new software product category to mature to the point where comparable open source projects can emerge. Not everyone can wait that long...
No offense man, but roughly 10 years ago Java was released in beta. A whole industry has been created and had a chance to have 'mature' players in that time. I think your timeframe is off by a facter of 2 at least, more like 3. :)
|
|
|
Message #182907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nice article, but...
Your model objects are going to look awfully non-modelly with all that code inside them. Maybe that's not what you meant, but the code has to go somewhere, and I'd put it in a controller if nothing else.
Well, you could put it in a "service" which encapsulates both your model objects (aka schema) and your view-independent business logic (validation, auth, etc). Whatever you call it in your system, this code is clearly behind the model boundary in a MVC presentation layer. You would use the same code for server-to-server calls, where there is no view whatsoever.
No offense man, but roughly 10 years ago Java was released in beta. A whole industry has been created and had a chance to have 'mature' players in that time.
None taken. Not sure what product category you have in mind, maybe virtual machines, maybe app servers, maybe something else. Anyway, I think most folks on TSS would agree that AJAX RIA platforms are a relatively new product category.
|
|
|
Message #182949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
I have explored bit of RICO and SmartClient and both are pretty cool.
Just wondering about security aspect of the various tools mentioned in the discussion as recently big giants like Google, AOL, Yahoo etc. were struck by Ajax security hole in CPAINT, another popular Ajax development tool.
More at http://www.xatrix.org/article.php?s=4040
Shishank
http://goshishank.blogspot.com
|
|
|
Message #182979
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
I have explored bit of RICO and SmartClient and both are pretty cool. Just wondering about security aspect of the various tools mentioned in the discussion as recently big giants like Google, AOL, Yahoo etc. were struck by Ajax security hole in CPAINT, another popular Ajax development tool.
That particular case was just a publicity stunt to attract attention to a new project. None of the companies mentioned in that article use CPAINT. The project just kicked off two months ago.
As I understand it, the bug was that their server would execute any code passed from the client. That is an issue with very early prototype code, ~not~ an AJAX security hole. It was irresponsible and misleading to report it as an AJAX issue.
But to answer your question --
The platform for AJAX applications is the same as that for non-AJAX web applications, so the underlying security holes are the same. However, since client-side page rendering and client-server RPCs are fairly new to most web developers, it is more likely that they will overlook some of the issues. Some of the more common cases include:
* quick & dirty RPC mechanisms that allow arbitrary code execution on the server (eg the bug in CPAINT)
* client-side script injection (XSS exploits) not blocked in your component HTML renderers
* overly-permissive proxies that allow arbitrary cross-domain scripting
If you need to implement AJAX applications in production, security is one good reason to evaluate the commercial solutions. Performance, stability, scalability, and interoperability are some other good reasons.
Hope this helps,
Jeff Dill
Isomorphic Software
www.smartclient.com
|
|
|
Message #183010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This looks great for some one who has swing experience.
I like it, but I have not tested it.
|
|
|
Message #183536
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Article from java.net: Developing AJAX Applications the Easy Way
Thanks Jeff for the information.
I too agree that Ajax in itself doesn't pose any security threat but it all depends on the underlying application.
Is there any matrix/data available that compare various Ajax tools based on the parameters you mentioned before.
Shishank
http://goshishank.blogspot.com
|
|
|
| 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)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, 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)
|
|
