Greg Murray's Blog

AJAX Solutions Online : A demo is better than 1000 words

The BluePrints Solutions Catalog has been updated this week. In it are many solutions on AJAX that cover show the programming model we are proposing for AJAX applications that run on the Java Enterprise Edition platform.

Download or view the BluePrints Solutions Catalog at http://bpcatalog.dev.java.net/nonav/solutions.html.

Check out the live solutions below:

Autocomplete

Basic Progress Bar

Realtime Form Validation

Refreshing Data

Missing online are the next generation AJAX + JSF components which I see as the future for AJAX development on the Java Enterprise Edition platform. We are working to get those online as well. The JSF based AJAX components are part of the BluePrints Solutions Catalog that you can download and run today.

What do you think?

Comments

• Greg,Please tell us a bit about "the next generation AJAX + JSF" components.Will these be compatible with environments like Sun's Java Studio Creator? Will I be able to just import them and use them... or will they constrain my overall webtier design?I do intend to downloan the blueprints eventually... but I'd appreciate a preview.Thanks,--John

  Posted by: johnreynolds on August 29, 2005 at 05:59 AM

• Eh. Real-time form validation: nice concept, but...

  (1) Slow to update between valid ("duk") and invalid ("duke").

  (2) Furthermore, when I type that final "e" and hit "submit" before AJAX has a chance to update the screen to "invalid", I get a nasty error screen, instead of simply getting the original page back w/a message about the account name already being in use.

  The 2nd point indicates to me that the developer expects the AJAX spiffiness to be the ONLY validation. In that case, this demo fails to show off AJAX, really.

  It seems to me that AJAX-enabled pages ought to work properly even if the AJAX requests don't get processed.

  Sorry to be curmudgeonly.

  John.

  Posted by: jlusk4 on August 29, 2005 at 06:42 AM

• Ok, I went and took a quick gander at the index.html source code in the blueprints. Looks like it's all hand-coded.

  It seems to me that what I'd like is:

  Dead simple JSF usage. <aj:inputDate id="denialDate" value="#{denial.date}" min="#{encounter.admitDate}" max="#{encounter.dischargeDate}" /> <aj:message for="denialDate" styleClasses="invalid-msg,valid-msg"/> and THAT'S IT. No separate need to <script src="/js/ajaxDateValidation.js"/> or handcode any javascript.

  No user confusion while the server chews on new data. Users have REAL short attention spans and are easily confused. Heck, I'M easily confused. "I know this date's valid, why does it still say invalid? Is there something wrong w/the discharge date? I'll change it. Oh, NOW it's valid [because the AJAX response finally came through, not because the d/c date got changed]. Oh, wait, now it's INVALID again [because the d/c update AJAX request finally came through]! I'm so confused!!" Maybe we need four or five states for the validity message, not just two: "valid", "invalid", "was-valid-but-we're-rechecking", "was-invalid-but-we're-rechecking", "display:none-pay-no-attention-to-that-small-man-in-the-corner".

  (And, if slashdot, written in perl, can honor paragraph breaks in plain text, why can't java.net? Why am I forced to write html?)

  John.

  Posted by: jlusk4 on August 29, 2005 at 07:10 AM

• John,

  I recommend you take a look at Oracle's ADF library for this kind of functionality. They have dropable wars that have AJAX-like functionality under the same syntax you expressed in your comment.

  
  What you are looking for is do-able as the JSF spec stands, just like any other component framework, but I'll take the blueprints as examples, not as completed components

  Posted by: jhook on August 29, 2005 at 10:32 AM

• Thanks for the followup.

  Do you happen to know the licensing terms of ADF? The last time I looked (a few months ago), it looked REAL nice, but we don't develop w/Oracle tools and I couldn't tell what the licensing terms were.

  John.
  

  Posted by: jlusk4 on August 29, 2005 at 01:34 PM

• 
  So we have documented the JSF + AJAX strategy at https://bpcatalog.dev.java.net/nonav/ajax/jsf-ajax/frames.html. There are two components which follow this strategy in the solutions catalog which are the progress-bar-jsf and the textfield-jsf (autocomplete) components. The autocomplete component will work in creator (see Tor's blog on this at: http://blogs.sun.com/roller/page/tor/Weblog?catname=%2FAJAX). Moving forward we are looking at other components that will cover more usecases.

  
  The first generation of components that we looked at which are linked to from this blog contained hand written page specific JavaScript making them really one-off solutions. The JSF components are meant to be reused.

  
  As for the latency there are strategies out there for improving the experience that still require more investigation. We plan to address these more going forward.

  Does anyone out there have any thoughts on strategies for dealing with latency?

  Posted by: gmurray71 on August 29, 2005 at 04:07 PM

• when a component is querying the db, disable that input element or specify a dependency between the form and the child components such that each child component 'decorates' the onSubmit method in order to predicate submission while querying via JS/DHTML events.

  Posted by: jhook on August 29, 2005 at 04:54 PM

• The details of the JSF+AJAX is great and helps a lot in understanding the behaviour. Good work. Its good to see that lot of happenings on Ajax in world these days.

  Posted by: johnajax on October 18, 2005 at 12:03 PM

• Have you, or do you know of a way to do cross domain requests without signing the scripts?

  I'd like to find a way to pull rss feeds from other domains onto my own without running into the "Permission denied to call method XMLHttpRequest.open" problem.

  Posted by: talksure on May 17, 2006 at 07:27 PM

• In the case you describe you will need a server side component like a servlet within your domain to go out and fetch the feed and then proxy it back to your client. It is not possible to make a call using the XmlHttpRequest. We have such a servlet as part of the Project jMaki RSS reader at https://ajax.dev.java.net. The RSS reader proxy service will expose a feed as JSON. On the cross domain not you may want to look at Dojo's cross domain loading.

  Posted by: gmurray71 on May 18, 2006 at 08:51 AM

This work is licensed under a Creative Commons License.