GWT Pronounced "Gwit"
As in "nitwit." Lord. I’m not sure that’s a good pronunciation, sort of like "Drools" (now JBoss Rules) that made management roll their eyes at its mention.
As in "nitwit." Lord. I’m not sure that’s a good pronunciation, sort of like "Drools" (now JBoss Rules) that made management roll their eyes at its mention.
Just here a short while and I’ve already heard some interesting notions from some hardware vendors (SANS, Firewalls, etc.) about how GWT might be the key to solving their deployment problems. Right now, many of them use Java (write once, run anyware, etc.) to write the desktop administration applications that manage their hardware. But Java is not trivial to package up and deploy for different OS’s. Many of these vendors seems to be considering GWT as an alternative, i.e. you get the RIA experience without having to deploy anything past a browser on the client.
More evidence that the browser is being viewed as an application platform, i.e. an operating system.
The day has finally arrived: Ext JS 2.0 received its final public release today. Judging by the timeouts I’ve been getting all morning when trying to connect to the Ext site and blog, I’m not the only one who’s been waiting anxiously. Originally tied to the YUI framework but now a standalone library, Ext provides the best example I’ve yet seen of a completely client-side framework for desktop-style RIAs.
As Ajax libraries multiply, they need to differentiate themselves to get my attention. Ext does just that, providing a top-to-tails solution for GUI components: tabs, trees, grids, you name it. Prototype, jQuery, Mootools and Dojo provide powerful general-purpose tools for Ajax development. Ext, on the other hand, uses a component model whose baseline configuration gets you 90% of the way there and whose extensibility gets you the rest of the way. It’s a huge achievement that Ext does so while embracing Web standards and user experience design. You don’t use Ext to sprinkle a little Ajax on your Web 1.0 application; you use it to build powerful, data-centric applications from the ground up without relying on GWT or .Net to write your JavaScript for you.
For the example application I’m building to show off Really Simple History, I’m constructing parallel versions with Prototype, jQuery and Ext. Frankly, it’s the Ext version that I’m most excited to show off. I’ve been waiting patiently for a couple of months to find a hole in the schedule of busy Ext creator Jack Slocum. Now that Ext 2.0 is out there, I hope to publish an interview with him in this space soon.
With the Ext servers struggling to meet demand, you may have trouble trying to download the library, read the announcement or peruse the completely overhauled documentation. In the meantime, you can read this exhaustive Ajaxian post about all of the changes and new capabilities.
Really Simple History 0.6 rolled over this morning from release candidate into final production code. All previous versions are now considered deprecated. The production version of 0.6 is exactly the same as RC1, but it includes more complete release notes and a minified version of rsh.js. (Much respect to Dojo ShrinkSafe!)
I’d like to extend thanks to the many tireless beta-testers who have put RSH through its paces over the last couple of months. Thanks also to the many developers whose work on other Ajax history frameworks has informed my own. Most of all, thanks to Brad Neuberg for initiating the project and allowing me to get my grubby little paw prints all over it.
As always, you can download RSH from its home at Google Code and participate in the RSH community at its Google Group.
The roadmap from 0.6 to 1.0 is taking shape:
0.8 will become available for beta testing by the end of the year. It will include the following enhancements and changes:
1.0 is scheduled for 2008 Q1. It will include full jsUnit and Selenium test coverage.
This can occur for several different reasons. For example, http://opensource.atlassian.com/projects/spring/browse/SPR-1598. Here is how I came across: Missing hibernate mapping file (hbm.xml) in hibernate SessionFactory.
When we forget to list a hibernate mapping file (*.hbm.xml) during SessionFactory creation, it usually fails fast. This fail fast happens since there is another domain-entity mapping that has many-to-one relationship with this class. However, if a given domain-entity is not being referenced by any other entity mapping file, then Hibernate (obviously) will have no knowledge that this entity-exists.
This is fine, but you expect your query to fail with proper error message when any hibernate query method is called in relation to an unlisted entity. For example, I have a User entity in addition to many other entities. For the sake of argument, let us say that no other entity refers to User entity. So, if I list hibernate mapping files (*.hbm.xml) for all entities except User.hbm.xml, SessionFactory creation won’t fail. This is fine since SessionFactory has no magical way to figure out how many entity-classes should have their mapping defined and listed.
However, it should fail when I call methods like Session.createQuery("from com.package.User as s where userName=?"). You would expect Hibernate to fail-fast and complain about un-mapped class (com.package.User in this case). It doesn’t. Under these circumstances, trying to execute hql query with positional parameter gives "java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based!". Trying to run query with named-param will result in ‘org.hibernate.QueryParameterException: could not locate named parameter [<paramname>]". None of these errors say anything about the unmapped entity.
Related Services: Java Application Development, Custom Software Development
