|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 42
Messages: 42
Messages: 42
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Ajax using XMLHttpRequest and Struts example online
Frank W. Zametti has written an article and accompanying webapp that shows simple usage of Ajax (Asynchronous Javascript + XML), specifically within a Struts application. Mr. Zametti walks through how Ajax is working, why it might be used, and how to apply it in a number of interesting usages of Ajax, including a sortable table and an RSS feed parser, with full code.
Links:
|
|
|
Message #164592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax using XMLHttpRequest and Struts example online
I haven't done stuff like this for some years, but I seem to remember that you could do this sort of thing in a browser neutral way that even worked in netscape 4.7. You would use a zero sized inline frame and set the source to load a HTML document that contained your data. The ONLOAD attribute in the loaded page would trigger the update of your SELECT.
However, it always messed the back button history.
|
|
|
Message #164596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why not just use a rich client?
Likewise I've worked on an application that used this technique, and I couldn't help but wonder why we didn't just write the thing using something like Java Webstart.
I'm still not entirely convinced that the browser is the place to try and write rich clients, especially when it comes to testing the rich interactions that are possible. I also found it takes a lot to get the look and feel up to scratch on a web based rich client (especially between browsers), whereas with Swing (and the likes of JGoodies) it's pretty simple.
|
|
|
Message #164599
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Take a history lesson
We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore and why is that? Because it hard to detect errors and debugg applications. Performance was terrible, and chaning the UI became very hard because it was all messed up in the Java Script (which is also the case with the example in this article).
We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.
|
|
|
Message #164601
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agree, Danger
Likewise I've worked on an application that used this technique, and I couldn't help but wonder why we didn't just write the thing using something like Java Webstart.I'm still not entirely convinced that the browser is the place to try and write rich clients...
I agree with you, but I fear we're in danger of living in this world. If you look at the number of web app developers out there, and the amount enterprise have invested in web applications, something like this could provide just enough incremental improvement that it will quell the increasing demand for RIAs. I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs. The end result could be not enough demand for something better.
...especially when it comes to testing the rich interactions that are possible. I also found it takes a lot to get the look and feel up to scratch on a web based rich client (especially between browsers), whereas with Swing (and the likes of JGoodies) it's pretty simple.
I don't think people expect a native look & feel in a web app. In a web app, the native look & feel is a web page, not an application. Give then a more interactive web page and they'll be happy.
|
|
|
Message #164611
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Take a history lesson
We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore and why is that? Because it hard to detect errors and debugg applications. Performance was terrible, and chaning the UI became very hard because it was all messed up in the Java Script (which is also the case with the example in this article).We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.
XmlHttp can be quite useful, actually. I've used it for a long time before this "Ajax" acronym came about.
I mainly used it when I needed to fetch some data and didn't want to do a full post to the server. Most commonly it was used for dynamic drop down boxes. When you have a drop down that needs different data depending on what was selected. You could send the selection with XmlHttp and then add the response to the drop down without doing a form post.
It was easy to implement and performance was excellent.
I agree with you that the IFRAME hack was a horrible implementation. But XmlHttp can be quite useful if it's not overdone, which seems to be the case with "Ajax".
|
|
|
Message #164615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax using XMLHttpRequest and Struts example online
a better way is to use javascript to request an image from the server (obviously as small as possible) and attach the request to the cookie then read the parameters from the cookie on the server and send the response back using the cookie. Finally parse the cookie on the client side and you were done.
The weakness with this approach is that you are limited to 4k response, but for a lot of jobs it was a really easy way of sending a request without reloading the whole page.
|
|
|
Message #164626
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
0x0 Iframes
I haven't done stuff like this for some years, but I seem to remember that you could do this sort of thing in a browser neutral way that even worked in netscape 4.7. You would use a zero sized inline frame and set the source to load a HTML document that contained your data. The ONLOAD attribute in the loaded page would trigger the update of your SELECT.However, it always messed the back button history.
Yes, I've been doing this for quite a while. You can use Javascript to push parameters to the pages and even use it to update your main page.
There are a few oddities though as some browsers will show some of the iframe borders no matter the size. The solution here is to use absolute positioning to move it off the viewable screen... -100, -100 always worked for me.
For most of the sites I was doing this on, I would autodetect my login, multiply those by -1, and increase the size to make it useful for debugging purposes.
|
|
|
Message #164641
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
you got it
We have been down this road before, there is no reason what so ever to re-open this can of worms. I realy think people should take a brief history lesson before claiming that using the XmlHttpRequest object is the road to heavenly webapplications. When what it realy is, is a a trip down memory lane.
+1
Leif really got the point about the risks of Ajax and why someone should really have strong arguments using it, other than just playing around and trying to be google.
Marc
|
|
|
Message #164645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
forget the x in Ajax
Any download from JavaScript should use JSON (JavaScript Object Notation) instead of XML. This format is naturally integrated in JavaScript.
On the server side, Java primary types and Collections are marshalled using a simple library. And on the client side, browser independance is managed by an external script.
You still have to use the returned data (using JavaScript Templates for instance) and put the result in the page (with document.write or innerxxx)
See JSON-RPC-Java
(synchronous calls are not recommended, specially using Firefox)
|
|
|
Message #164661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RIA, Agree, Danger
I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs.
I imagine that eventually browsers would support SVG-2 and DOM Level-3 Load&Save, and that could be RIA. The folks best prepared for it would already have become Ajax literate. Ajax isn't a temporary hack until RIA arrives. Ajax is an essential piece of RIA.
|
|
|
Message #164664
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DOM Level-3 Load&Save, innerHTML
innerHTML is not a part of DOM
DOM Level-3 Load&Save standardizes features which previously were given as proprietary details such as innerHTML and XmlHttpRequest. RIA amounts to a completely and internationally standardized framework specified by W3C and ECMA.
|
|
|
Message #164674
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Take a history lesson
We all tried to do this when IE 4 came out, using hidden frames/iframes and other types of black magic. But, no one does this anymore...
Oh, so Google is no one?
|
|
|
Message #164675
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Different means, same end
I'm not saying it would be as rich, or as good, but this could be woven in to existing web applications a piece at a time, improving them -- satisfying some who would've otherwise wanted RIAs. I imagine that eventually browsers would support SVG-2 and DOM Level-3 Load&Save, and that could be RIA. The folks best prepared for it would already have become Ajax literate. Ajax isn't a temporary hack until RIA arrives. Ajax is an essential piece of RIA.
Well, I agree that it would achieve RIA, but that is not the RIA vision I and others have. I'd rather see the browser die, or' at most be yet-another-GUI-component in a new rich internet application framework. The browser is a container for web page renderings. I hope that RIAs are run tshrough RIA frameworks that render the applications as top-level GUI windows, not contained within some RIA browser. I don't need a "back button" and "address bar" in my RIA word processor.
That said, I don't think the end user will much care. So long as their experience at least incrementally improves, they'll be excited and happy. To get to my vision, we need a revolution, not evolution. But that people will be largely satisfied with evolution is what threatens to starve support for the revolution.
|
|
|
Message #164684
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Different means, same end
Well, I agree that it would achieve RIA, but that is not the RIA vision I and others have. I'd rather see the browser die...
SVG is RIA and doesn't need a web browser. Eg, Batik's Squiggle is WebStart deployable -- no browser needed. Whether the browser survives or not is irrelevant. GUIs will likely be encoded as documents, and RIA will likely be document oriented. That's why Ajax is so seminal -- it gives XUL extensible behavior.
|
|
|
Message #164685
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Another way of doing it...
One cool way of doing this is thru dynamic change of the src attribute of a script element. It's cool, because it also starts executing the script once it's loaded.
For example,
<script id="gateway" type="text/javascript"></script>
and then
gateway.src = "gateway.jsp?param1=value1¶m2=value2...";
It works on both IE and Mozilla and as far as I remember, even on their ancient versions.
I agree that it's not efficient to send XML this way, but the script can dynamically generate JavaScript commands, such as:
selectClear(xyz);
selectAdd(xyz, "1", "Computers");
selectAdd(xyz, "2", "Electronics");
This way you don't even need XML and the Business Logic stays on the server.
|
|
|
Message #164700
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Take a history lesson
I did take a history lesson:
- Using the technique to grab quick data to make your interface better to use and with less round trips (at least noticeable round trips) has been quite good with my customers
- Gmail. Need I say more?
Of course, reimplementing Swing in Javascript is a bad idea. But Gmail is brilliant.. I wish they would open up their framework.
|
|
|
Message #164706
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
<script src=, Another way of doing it...
For example,<script id="gateway" type="text/javascript"></script>and thengateway.src = "gateway.jsp?param1=value1&param2=value2...";
I wondered how XHTML would treat this. The XHTML specification gives an XLink definition of script activation that does not set the "effect=replace" hlink attribute of the script element's src attribute. I'm guessing your script reloading trick wouldn't be so easy with XHTML.
Also I wonder if SVG-2 script src uses XLink? It would be unfortunate if the two leading XULs (XHTML, SVG) had discrepant definitions of script element activation.
|
|
|
Message #164721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
<script src=, Another way of doing it...
I had done something like that long time ago. By using document.createElment("script"), and onload event handle
It only can do a GET request, not a POST,
But there have another big problem. The browser MAY have memory leak.
The reason using XMLHTTP object. It is the only way to do low level http request, which you can handle it. It is safe, security, no addition heavy dependency. And it is cross browser.
|
|
|
Message #164731
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Take a history lesson
There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.
If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object. Then you have tons of Java Script outputting HTML.
This was not a good way of doing things last century, and it still isn't.
|
|
|
Message #164739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The emperors new clothing
There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object. Then you have tons of Java Script outputting HTML. This was not a good way of doing things last century, and it still isn't.
My thoughts exactly. But then again, let the emperor be naked, just as long as he keeps out of my backyard.
|
|
|
Message #164754
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Outlook Web Access
I agree! AJAX is much better and I am using it for more than 3 years at work in a product, which supports only IE. By using AJAX, XSL (client-side), and sometimes even XDI (IE's XML Data Islands), we've done some nice things.
I agree that IE has a memory leak, when you use dynamic script loading and it's limited to just "get" method. I am not recommending it at all!
I don't understand why people associate AJAX primarily with Google and "wow" so much about Gmail. Google Maps is something amazing, I agree! But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003.
|
|
|
Message #164760
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Outlook Web Access
But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003. You think OWA is fast? Not with IE. It takes a long time to load up (on different machines and different mail servers in different organizations). I mostly use Firefox with it so it will work faster. Of course some of the functionality is gone (like search). I would rather use Thunderbird but I can't always plug up my USB memory stick.
|
|
|
Message #164767
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
0x0 Iframes
There are a few oddities though as some browsers will show some of the iframe borders no matter the size. The solution here is to use absolute positioning to move it off the viewable screen... -100, -100 always worked for me.
FRAMEBORDER="0" ?
|
|
|
Message #164769
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can AJAX be used to logout an user on session timeout
I have never heard of AJAX before...(Yes...was in a cave...so pardon me:) [[Since I am a soccer nut I thought you folks were talking about the numero uno soccer club of Holland...but I digress..]]
Question:-
Can AJAX be used as a "neater" technology to logout an user from a webpage when his session expires? (I am focused on the term "asynchronous" in the full-form of AJAX)
Well if that is a dumb question...I must be really dumb:)
|
|
|
Message #164778
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax name origin
One possible origin for its name: http://www.in2greece.com/english/historymyth/mythology/names/ajax.htm
There are tons of interesting greek mythologycal names there too, so this could be a good source if you're looking for a name to your brand new open source framework... :)
About the logout thing, I am not sure what you meant. If what you want is some way the server can fire some procedure on the client side, I don't think AJAX will be the answer, as only the client side can start a call to the server, and not the other way around.
Regards,
Henrique Steckelberg
|
|
|
Message #164785
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Phat client, RE: Take a history lesson
There is no "magic" in Gmail or Google Suggest. There's just plain old Java Script.If you do a search you will see theres tons of people who've picked apart the google code, and all you've got is some functions wrapping arround the XmlHttpRequest object.
Magic or no, if it blows away the crappy web pages we're coding now, then it still counts as an improvement, likely an evolutionary improvement.
Then you have tons of Java Script outputting HTML. This was not a good way of doing things last century, and it still isn't.
It sure is hell to develop by hand. But if the DHTML is encapsulated and generated by reusable server objects (eg JSF renderers), then it's painless. GMail may have hand coded DHTML, but mainstream DHTML is eventually more likely to be generated when the craft matures. The beauty of DHTML is that it is very easy to generate -- without many of the headaches associated with using BCEL or Janino to generate Java logic. That's because interpreted scripts are easier to generate.
The rise of DHTML doesn't necessarily mean more hand coded DHTML. Eg, Hibernate's generative encapsulation is in many projects eliminating the need for hand coded SQL. SQL is an interpreted language, a thing that can be easily generatively metaprogramed, and Hibernate proves it. DHTML could also be tamed the same way (perhaps as JSF renderers). I absolutely expect this to dominate the fat client arena (by outcompeting Swing/WebStart), especially when XHTML is replaced or combined with SVG-2. XHTML, SVG, and ECMAScript are all international standards that get revised occasionally. Who wants to compete with that?
|
|
|
Message #164790
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Outlook Web Access
I agree! AJAX is much better and I am using it for more than 3 years at work in a product, which supports only IE. By using AJAX, XSL (client-side), and sometimes even XDI (IE's XML Data Islands), we've done some nice things.I agree that IE has a memory leak, when you use dynamic script loading and it's limited to just "get" method. I am not recommending it at all!I don't understand why people associate AJAX primarily with Google and "wow" so much about Gmail. Google Maps is something amazing, I agree! But if we have to really "wow" about a flexible and high performance web-based mail client, nothing beats Outlook Web Access that comes with Exchange 2003 (I'm not sure if it uses AJAX, but it seems to)! You simply forget that this is a web application and amazingly it's faster than the desktop Outlook 2003.
Outlook Web Access is implemented with ActiveX objects which is why this albeit very cool, "high interactivity" mode only runs in IE. If you open it up in Mozilla you'll find the application doesn't function quite as well, which is of course the Microsoft way of doing things.
|
|
|
Message #164795
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can AJAX be used to logout an user on session timeout
I have never heard of AJAX before...(Yes...was in a cave...so pardon me:) [[Since I am a soccer nut I thought you folks were talking about the numero uno soccer club of Holland...but I digress..]]Question:-Can AJAX be used as a "neater" technology to logout an user from a webpage when his session expires? (I am focused on the term "asynchronous" in the full-form of AJAX)Well if that is a dumb question...I must be really dumb:)
The server would have to have a way of pushing an unrequested message to the browser, letting it know the session had timed out, which is not supported by http. You open up a whole can of worms about firewalls, security, etc just thinking about it.
You could have something on the client side that periodically sends messages to the server to see if the session has timed out, but that would in fact keep the session open! :-)
If a request was sent to the server and the session had timed out, then an appropriate response could be sent to the browser, which would have to have code on how to handle that event, but this would be logout AFTER the session has expired instead of WHEN the session has expired.
"There are no dumb questions, just dumb answers."
Thad Smith
|
|
|
Message #164849
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
developer.apple.com article
This article covers similar material to the article http://developer.apple.com/internet/webcontent/xmlhttpreq.html posted on the apple site last year (there is another article on submitting forms remotely, http://developer.apple.com/internet/webcontent/iframe.html, that is also good (and related)). Actually, google was not close to being the first to use this - it seems like they get too much credit; clearly Apple has used this for a while, and Plumtree built it into their portal early last year.
As a side note, d/t strange ActiveX inconsistancies, if you want these techniques to succeed 100% of the time it's good to use IFrame as a 3rd option when the first two don't pan out.
|
|
|
Message #164918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax using XMLHttpRequest and Struts example online
There is nothing new in this article that could help users get a much firm control over this approach. Similiar to the original Apple article
|
|
|
Message #165044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can AJAX be used to logout an user on session timeout
I am focused on the term "asynchronous" in the full-form of AJAX. ... Well if that is a dumb question...I must be really dumb
It's not dumb. I think the "asynchronous" must refer to scripts in a web page making requests to the server and receiving responses without an entirely new web page returned. However, every response from the server is still the result of a request from the client, otherwise we would not be able to do it using the http protocol.
As hinted at by someone above, a page can use a window.setInterval() to keep the session alive on the webserver. This is sometimes called "polling". This allows the session timeout on the webserver to be set very short, and so the user can be registered as logged out almost as soon as the user closes the browser.
To do it the other way around and have the browser close or logout on a timeout is a bit more tricky. You would need your form of timeout, this would need to keep track of the time of the last request (not including the polling requests). The polling request would then calculate if the timeout has expired and when the response is returned to the client, it could then trigger the log out request (probably by requesting a new web page - automatically closing the browser would probably not be allowed).
|
|
|
Message #165076
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Google seems to like it extended
I don't specialy disagree with you. If only we could put invisible applets everywhere and use a real language instead of JavaScript. But you indeed feel like you gained a new superpower with a browser independent library.
The real software evolution is when faisible things become easy.
A sentence as an answer ?
|
|
|
Message #165118
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
you got it
Hello,
xmlHttpObject is very useful in certain scenarios. For example , in a application that I developed, there was a necessity to show huge hierarchical data. Instead of fetching the whole hierarchy at one shot (which was not efficient starting from the database level), we implemented that using xmlHttpObject. So once the node is clicked, the children are fetched on the fly !!!!...
Our users are so happy with this solution as
1. The page was not refreshing
2. The page loading was very fast as the initial data displayed is less.
I'm planning to widely use this stuff going ahead. Thinking of one such scenario is sorting tables on click of the headers. The second useful one would be refreshing of a single portlet in a portal application .
-sunda
|
|
|
Message #165297
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
everyone got it
there are even lots of commercial dhtml based web user interface components available from several vendors. there are several different companies providing comboboxes and others still with complex excel-like data grids that let you do data paging, editing, deleting etc all without refreshing the browser.
these seem necessary for many applications such as financial where they may be editing thousands of records. in that sort of situation if you can reduce the amount of time it takes to edit each record by a factor of 5 you are talking about big time savings! not to mention the fact that it just feels nicer for the end user.
dave
|
|
|
Message #165594
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Investment in webapps...
If you look at the number of web app developers out there, and the amount enterprise have invested in web applications, something like this could provide just enough incremental improvement that it will quell the increasing demand for RIAs.
Not too sure I'd go for the incremental improvement you've just mentioned... personally I'd rather invest time getting the server side of the app modified so that it could run using either a web browser client, which is not rich, or a Swing/SWT/other rich client.
I also wasn't saying the browser had to mimic a native look and feel, I was really only talking about general layouts, especially when trying to use CSS without tables, and resizing between browsers...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore 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.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
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)
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)
|
|
