Ext Conference, Day 2
After the 100mph pace yesterday, day two of the conference settled in to a comfortable 55mph. The big news of the day was during the keynote, when they released RC1 of ExtJS 3.0. Jack was the scheduled keynote speaker, but I get the impression he doesn’t like speaking in front of large groups. His keynote lasted all of five minutes. He covered the history of ExtJS in two minutes and said ExtJS 3.0 is here. And that was it. Abe was left scrambling to fill a rather large hole in the schedule, and he called up Darrell of the GXT (Ext GWT) team to talk about their v2.0 release.
Darrell is a nice guy, but I was ready to pull my hair out listening to him. I had lunch with him yesterday and to say he is excited about GWT is a major understatement. In spite of being a Java guy, I don’t like the idea of writing my web UI in Java. It’s like the Hibernate mafia who think you can write a database application without knowing SQL. Each of the tiers has a best-in-breed language for addressing that tier’s problems. An enterprise developer better know SQL for talking to databases, Java/C# for the middle tier and HTML, CSS and JavaScript for the front end.
After the keynote, we had another smoothie break. The smoothies were good, but the general consensus would have preferred coffee in the morning and smoothies in the afternoon.
Aaron kicked off the regular sessions with a breakdown of the signature demo in ExtJS 3.0 — Image Organizer. This is the meatiest demo so far, and was interesting to see how they structured the code and where they subclassed. The application uses Ext.Direct, but the backend was only PHP. One of the first questions Aaron got asked was when they would release other backends. He really danced around the question without giving a true answer, saying that maybe there would be something released in the next week or so. Ext.Direct is starting to sound like a lot of vaporware. They talk a good game of how it will be able to use annotations/attributes server side for exporting objects and other cool stuff, but no one is producing any code. Ext.Direct is the new Duke Nukem Forever.
The next session I attended was one of the funniest. Glen Liptka talked about user experience design with ExtJS. He is at Marketo, which has done the most incredible theming of ExtJS I have ever seen. He started the talk covering general usability and then demonstrated their application. The point he made that stuck with me is that your UI should have low WTF/min. Everyone got a kick out of that.
Next up was JC Bize talking about theming ExtJS. JC is the author of the Slate theme, one of the most popular third-party themes used in ExtJS. He is now an employee of Ext, LLC, so hopefully we’ll see some more cool themes in the pipeline. He showed off a couple cool themes and then got in to a basic example of how to change the theme of a panel. When playing with themes, Firebug is your friend. Unfortunately, he got sidetracked trying to answer an audience question and the presentation fizzled out.
I couldn’t catch the last session, as I had to make a phone call, but came back for the day-ending Ask the Ext Team. Nothing major came up. I tried to ask the question of why they didn’t use Sizzle for Ext Core, but my question didn’t get voted up and they ended the session before they got to it.
The day wrapped up with a social down by the pool with a cash bar. I really started to hate the Ritz after paying $8 for a beer. They definitely need to move the conference to someplace that understands Happy Hour. I managed to corner Aaron at the social and got my Sizzle question answered. He said they didn’t use Sizzle because it was too big and too slow. He did say the DOJO guys were working on a very cool new engine called Acme that looks promising. DOJO makes me nauseous just looking at it, so I won’t be investigating it.
The day ended for me again at the bar. I had dinner with another attendee who works at the DIA. Since I have a similar background, we had a lot to talk about. $35 for two margaritas and a plate of chicken quesadillas — ouch!
Day three is only a half day, but there are still two sessions I’m interested in, so it should be fruitful.
Ext Conference, Day 1
The first day of the first-ever Ext Conference wrapped up today. The day actually started last night when I got to the hotel. Jay Garcia and Shea Frederick both got in at about the same time as me. We had an impromptu meet-up at the hotel bar, where we hooked up with a few more conference attendees who were drawn to the geek conversation like moths to a flame.
One of the guys (Jerry), mentioned that Abe (Elias) was still in the big conference room preparing for the keynote. Since it was 12:30am, and tipsy geeks don’t have anything better to do, we paid him a visit. He was extremely cool, and ended up giving us the tour. He took us down to one of the other meeting rooms where a Rick, Aaron, Evan, Tommy and Chris were getting ready for their presentations too. After about a half-hour of the geekfest with them, I went to bed to be ready for the early start today. As a footnote to the evening, be sure to ask Jay how sissy drinks at the Ritz went over with him.
The conference started up at 8:30am this morning. Abe introduced the Ext development team, which was a lot larger than I expected – over a dozen people. He kept the introductions short so that we could get to Douglas Crockford, our keynote speaker. As he is a legend in the JavaScript community, it was exciting to see him talk in person. He covered a little bit of the history of JavaScript, then dived in to the future, including ECMAScript 5 (ES5). ES5 is going to be pretty impressive, but it will be years before we can really count on it being on all the desktops (thanks, Microsoft).
Most all the sessions throughout the day were at a good technical level. No fluff, just stuff. Aaron presented the new features of ExtJS 3.0, which drew almost everyone. They had to move the session back to the keynote ballroom. ExtJS 3.0 is super cool, with one exception, which I’ll discuss below.
Evan was up next, talking about Ext.data. Since there wasn’t a lot new in this space, this was more a rehash of the Ext.data classes. Evan definitely knows his stuff, and had some educational examples.
Chris then talked about Ext.direct. This is the one area of ExtJS 3.0 that I’m still skeptical on. One of the key parts of Ext.direct is the server-side component, yet everyone so far has been light on details for this piece. Chris is a Merb guy, so it didn’t help when he was showing Ruby code trying to explain it. Even listening to Jack discuss it in the hall left me feeling there were still a lot of smoke and mirrors around Ext.direct. In theory, Ext.direct should provide a server-technology agnostic RPC mechanism for talking to objects. I’m not convinced we actually needed this, and since I haven’t seen any real code behind it, I’m not sure what kind of state it is in. Hopefully, when Jack announces the release of ExtJS 3.0 tomorrow morning, I’ll get a chance to look at some code.
My final session for the day was watching Tommy discuss Ext Core. I’ve already covered Ext Core in some prior posts, but still managed to learn some things. Ext Core is going to really shake some things up when folks start to get familiar with it. I plan on wrapping up a post on the cool OO features of Ext Core this weekend.
That was it for the structured presentations. Here are a few other random thoughts and observations on the day:
- Swag so far has been an Ext spiral notepad, a pen and a nice travel mug. There will probably be a riot if T-shirts don’t appear.
- The next fool who gets up and asks about testing ExtJS websites with selenium is going to receive my travel mug upside their head. Asking the same question five times is not going to get you a different answer.
- The meal was excellent. The hotel is nice, but a bit too ostentatious. It’s the Ritz, so you have to expect it, but it would have been more fun to have the conference in a more festive environment. Hint for Abe: Vegas, Baby!
- Overheard a Salesforce architect talking about them moving to ExtJS. That would really rock if they did it.
- The average age of the Ext dev team appears to be about 17
. They have a lot of bright, young talent on their hands. It will be fun to watch what they do with it. - Someone actually asked, in the group Q&A, if there were any books on ExtJS. Paying over a thousand dollars for a conference and not doing your homework is just plain dumb. Never ask something in front of a large group that 15 seconds on Google or Amazon could answer for you.
- All the sessions were taped and Abe said they would be put up on the Ext site. Presentations should show up too.
I’m hoping tomorrow rocks too. We went non-stop from 8:30am to 6:30pm today, and it was a lot of fun. If they can keep up the momentum, this will turn out to be one of the best technology conferences I have ever attended.
Feedback
It has been fun watching the comments on my write-up yesterday about Ext Core on some of the sites it got posted to. It is clear, for some people, discussing JavaScript libraries has drifted into the same hazard zone as discussing religion and politics. While I appreciate all the feedback, and probably should have signed up for adwords before posting, I do want to clarify a few things:
- GPL – I hate it, deal with it. There are two reasons a library author would use GPL. First, to prevent someone else from monetizing their effort (ala ExtJS), or second, because open source is an agenda and not a license. An altruistic developer who is interested in helping other developers without expectations of a return will use a reuse-friendly open source license for their libraries like Apache or MIT. If you’re trying to change the world, please, go ahead and use GPL. If you just want to help out your fellow developers, use something with no strings attached.
- ExtJS Haters – still a surprising number of geeks out there who are bitter about the change from LGPL to GPL. I was a vocal critic of the change too. I got over it — I bought a license and no longer care. Best $289 I’ve ever spent. If you’re looking for a free ride, look elsewhere. Ext LLC is for-profit entity and I agree with them. People should be able to put food on the table writing cool code, and I won’t deny the talented developers at Ext LLC that right.
- Fluff – I especially got a kick out of this. It was the longest blog post I have ever written (1800+ words) and tried to touch on as many areas as I could. I plan on following up with some more detailed posts. Guess you can’t make everyone happy.
- The Conclusion – JQuery is an awesome library. I’ve used it for years. I’ve also used ExtJS and will now use Ext Core more. Why? For the same reason some developers gravitate to Perl and others to Java — Style. I come from a OO Java background, and thus the coding style of the whole ExtJS/Ext Core duo is more in line with my preferred comfort zone. Both JQuery and Ext Core are awesome libraries. Pick the one that suits your personal style and objectives.
New Kid on the Block
On this cloudy Dallas Saturday morning, the ExtJS team announced the availability of Ext Core (beta). Ext Core is the core DOM selection, manipulation and events library of ExtJS which has been extracted out into a separate library released under a more liberal license. They smartly released this under the very permissive MIT license, in contrast to the cancerous GPL used for the full ExtJS.
What makes this interesting is it positions Ext Core as a direct competitor to the popular JQuery library. I really like both ExtJS and JQuery, so I decided to run a quick comparison of the two libraries to see if Ext Core is up to the task of replacing JQuery in my developer toolbox. Since there is so much overlap between the two, it makes no sense to use both.
Round 1 – Size
Library size of the two is pretty close. The minified version of JQuery runs about 56K, while the minified version of Ext Core weighs in at 75K. The 19K difference might matter for an iPhone application, but even then, I would consider it negligible. Both are pretty small libraries, so we’ll call Round 1 a tie and move on to feature comparison.
Round 2 – Load Event
How each of these libraries works the document ready event is more a matter of style. The JQuery convention is to use the dollar sign ($) for for operations, although you can fall back to using the full name (jQuery). Setting up a ready event in JQuery looks like this:
$(document).ready(function() { // do cool stuff });
Ext Core uses the static Ext class for the same functionality. Like the jQuery object, the Ext object is the heart of Ext Core. Setting up the ready listener in Ext Core looks like this:
Ext.onReady(function() { // do cool stuff });
One big difference is the onReady method can take an additional parameter specifying the scope in which the onReady method should execute. This is not a big deal in most cases, but shows Ext Core’s attention to support object oriented JavaScript. Since I’ve never actually needed to specify the scope, I’ll call this round a tie too.
Round 3 – Selectors
This is the heart of both libraries, and a full comparison could fill a dozen pages. The short story is they both support basically the same set of CSS3 selectors along with some custom enhancements. From looking at the documentation, I couldn’t find any typical use cases that either couldn’t handle. Like the document ready example above, it just comes down to a matter of convention. For example, here is the code from each to add a class to a set of nodes:
// JQuery $('td.age').addClass('someclass'); // Ext Core Ext.select('td.age').addClass('someclass');
One major style difference between the two is that Ext Core has a tighter focus in handing elements with ids, since that is critical to the full ExtJS library. For example, Ext Core has the get() method to directly grab an element by ID, along with a memory-friendly fly() method. The fly() method does not create a new element wrapper in memory, and instead reuses a single global element object. This can save a lot of memory when you just need to do quick manipulations of single objects.
// Add a class to the element with ID of 'header' Ext.fly('header').addClass('someclass');
For the memory saving fly operation, I’ll give the advantage to Ext Core, although they are essentially equal in their DOM selection abilities.
Round 4 – Events
Like the selectors above, there are basically style differences between the two libraries in how they handle basic event use cases. JQuery adds some methods to the jQuery object for registering common events. For example, here is the code to add a click event to a button for each, including the JQuery shortcut:
// JQuery with bind() $('#myButton').bind('click', function() { alert('Clicked');}); // JQuery with shortcut $('#myButton').click(function() { alert('Clicked');}); // Ext Core Ext.fly('myButton').on('click', function() { alert('Clicked');};
JQuery brings some some additional enhancements to the game in the form of “live” events. This provides a way of attaching an event to all current, and future, instances of the selector. JQuery also supports event namespaces, where events can be fired in a hierarchy. Both are powerful concepts, but I’ve never had to use either.
The secret sauce for Ext Core is in extended configuration. With Ext Core events, you can also configure the scope (a common Ext Core theme), along with configuring the event propagation, extra parameters, and a delay. Here is a sample of a click event configured with ‘this’ scoped to the onClick event itself, to only fire once (single), with a delay of 100ms and an additional parameter (forumId) to be passed to the event handler:
el.on('click', this.onClick, this, { single: true, delay: 100, forumId: 4 });
So again, I’m going to call this round a tie. Both libraries handle simple event binding very easily. If you need the live events, the nod goes to JQuery. If you need the extra configuration options, Ext Core is your best bet.
Round 5 – DOM Manipulation
Once again, the two libraries provide a near complete overlap of basic DOM manipulation functionality. Each can easily create, move, add and insert DOM elements.
JQuery aims for convenience. For example, one feature of JQuery I really appreciate are simple methods to clear the content of a DOM element and set the text. For example, given:
<div id='message'>First Message</div>
With JQuery, it is simple to update the text:
$('#message').text('New Message');
The text() method removes all the child nodes of the matching elements and appends a text node containing the specified text. The text() method without a parameter will retrieve the text for a matching element. For Ext Core, you have to drop down to the DOM to set the new text value:
Ext.fly('secret').dom.innerHTML = 'New Message';
The Ext.Element class does not provide simple methods for setting the text or removing all the children of an element, which I find to be an annoying inconsistency.
On the plus side, Ext Core provides a lot more methods for manipulating the DOM. One of the cool ones is the radioClass() method. This method will add a class or classes to an element and remove that same class (or classes) from all the siblings. For example, here is a simple table with a row having the ‘selected’ class:
<table class="data">
<thead>
<tr><th>Name</th><th>Age</th></tr>
</thead>
<tr>
<td>Bill</td><td class="age">20</td>
</tr>
<tr class="selected">
<td>Alice</td><td class="age">21</td>
</tr>
<tr>
<td>Jeff</td><td class="age">22</td>
</tr>
<tr>
<td>Susan</td><td class="age">23</td>
</tr>
</table>This one line of Ext Core code will remove the ‘selected’ class from the current TR element and add it to the first row in the table:
Ext.select('table tr:first').radioClass('selected');
So for this round, I’ll give the advantage to JQuery for the more consistent API, especially around manipulating the text nodes of an element. This is something pretty simple for Ext Core to address, which they really should. Ext Core does, however, offer more powerful DOM manipulation options.
Round 6 – Effects
I’m not a big effects junkie, so I won’t have a lot to say about this. Both Ext Core and JQuery provide a very similar set of effects for elements (hide/show, fade, slideIn/Out, etc…). Ext Core provide a more powerful API for creating custom effects, while JQuery addresses this with its rather extensive set of plug-ins. I’m calling this one a tie.
Round 7 – AJAX
Ext Core and JQuery both make AJAX simple, but again, we’ll see that JQuery adds more simplified methods while Ext Core offers more powerful configuration. Here is a sample of an AJAX call that returns JSON data:
// URL returns a JSON object like this: {name: 'Tim'} // JQuery $.getJSON('http://myurl', function(data) {alert(data.name);}); // Ext Core Ext.AJAX.request({ url: 'http://myurl', success: function(response) { var data = Ext.decode(response.responseText); alert(data.name); } });
JQuery provides the simplified getJSON() method where the parameter to the callback has already been decoded into a JSON object. For Ext Core, the callback receives the XHR response object and you have to decode the text to JSON.
The Ext Core request() method demonstrates a typical ExtJS convention of using a JavaScript configuration object as a parameter instead of using multiple parameters.
Both libraries provide strong AJAX support, so we’ll go with a tie for this round too.
Round 8 – Documentation
There is no contest in the documentation department. While the JQuery documentation has improved, the Ext Core documentation blows it away. From the excellent manual to the high-quality API documentation, Ext Core sets the standard for what all documentation should look like.
Round 9 – Intangibles
For JQuery, the biggest intangibles are its plugins and support from Microsoft. JQuery is intentionally designed to provide a simple core set of functionality and to be easy to extend. There are hundreds of plugins people have written for JQuery in the Plugin Repository. As with all things open source, some are very good and some are kinda crappy, but you can be pretty certain to find a plugin that covers about anything you might be trying to do that is not covered by the core JQuery API.
Microsoft support is also a biggie. They have decided to include JQuery as a base JavaScript library in their web tools going forward. This means you won’t need to get special blessings to use JQuery in large corporate environments — it will be part of the core Microsoft bundle, with support and all.
Ext Core, being brand new, is lacking in both community and support. Ext LLC, the company behind ExtJS and Ext Core is a small software shop trying to get by in a tough economy. While their products are cutting edge, I’m expecting them to be bought out by a larger company before too long. I keep trying to talk my Spring Source contacts into buying them, but I have a feeling they’ll be bought by Adobe.
So from an intangibles perspective, JQuery is the winner. It is guaranteed to have longer legs under it, at least until we see where Ext LLC ends up.
Conclusion
Both Ext Core and JQuery are solid, complete base JavaScript libraries. JQuery leans towards simplicity while Ext Core offers enhanced configuration. The choice of which to use will come down to where you are now.
- If you use JQuery, and don’t anticipate using ExtJS, stay where you are. You’ve got a winner.
- If you use ExtJS and have used JQuery as a light weight option for when you didn’t need the widget library, Ext Core is now your library of choice.
- If you are in search of a JavaScript library, the choice is tougher. Unless there is a particular JQuery plugin you want to use, I recommend going with Ext Core. It starts laying the groundwork for using ExtJS, which you’ll want to do as you get in to building RIAs.
- If you’re a corporate Microsoft shop, you probably don’t have a choice. JQuery is now something you can slip by the infosec police without making waves.
Ext Core is definitely a winner. In the past, I have used JQuery for projects that need simple DOM manipulation and ExtJS for when I need the widgets, layouts, etc… Now that I have Ext Core, I don’t see using JQuery anymore for the simple cases. I can standardize on using the same API paradigm between Ext Core and ExtJS.
Follow-up #1: Beyond the Core
Follow-up #2: Slick Speed
Springing Around with ExtJS
NOTE: I have an update to this article which talks about Spring 3 with ExtJS 3.
While playing around more with ExtJS and Spring, I ran in to one of my favorite annoyances — setting up a new project. I can create a new webapp in IDEA (or Eclipse) and add some dependencies, but it is still pretty empty. Maven can go a bit farther, but I don’t like how it handles transitive dependencies. None of these will really give me a good starting point out of the box without either copying a bunch of stuff over from other projects or writing a lot from scratch.
To finally scratch that itch, and move further along the Spring & ExtJS path, I turned my demo project into a basic template. The zip archive that you can grab at the bottom is a fully-configured Spring web application, including Tiles, Spring Security, Spring MVC, custom JSON view, Transactions and a Datasource.
To get started, grab the file, extract it to some directory. Open a shell, navigate to the Template directory and run the ant command ant dist. This will compile the whole project and create a Template.war file in the dist directory. Note, I use Java 6 for all development, so if you’re not at least at Java 5, you won’t be able to use this.
Before you drop the war file into Tomcat’s webapp directory, you’ll need to setup the database. First, copy the jar files in lib/tomcat into Tomcat’s lib directory. This is the MySQL JDBC driver and the JTA files for transactions. You’ll then need to create a new database on your local MySQL instance called tomcat. For simplicity in development, create a user with all rights to the tomcat database. Here’s the code to run from a MySQL shell:
create database tomcat;
use tomcat;
grant all on tomcat.* to tomcat@localhost identified by 'apache';
Your other option is to just put in your MySQL root username and password. To do that, or change the connection string completely, edit context.xml under web/META-INF. If you don’t use MySQL, you will have to edit this file and also put the correct driver in Tomcat’s lib directory.
Once you have the database setup, drop the Template.war file into your Tomcat webapps directory and startup Tomcat. Assuming Tomcat is configured to listen on port 8080, you can open the sample by browsing to http://localhost:8080/Template
The application only has a couple pages. First, the login page:
Spring Security is configured to route unauthenticated requests through this page for login. You can take a look at the applicationContext-security.xml file in WEB-INF to see how this was done. There are two users configured for now. User scott with a password of tiger and user bob with a password of password. Yes, not very clever, but it works. Scott is in both the ROLE_ADMIN and ROLE_USER roles, while Bob is only in ROLE_USER.
If you login with scott, you’ll be taken to the index page, which looks like this:
The index page simply contains a text box with a button. Entering a message and pressing the button results in an Ajax call to the server which echos the message back to the page. An HTML element in the middle of the page is updated with the result via JavaScript.
You’ll notice in the footer of the page you can see the currently logged in user on the left, and a link to log out on the right. Clicking the log out link takes you to the logout page, which looks like this:
Again, nothing fancy. Just a message saying you have logged out and a link to login again. Use the login link to login as bob and try the echo functionality again. This time you get a different result:
This demonstrates what happens with Spring Security via annotations. Here’s the echo method in the service layer:
As you can see, the method is secured with an annotation indicating the user must be in the ROLE_ADMIN role to use the method. Bob is only in the ROLE_USER role, so the call to this service fails.
The application makes use of a ResourceBundleMessageSource for the pages mapped through the htmlDispatch servlet. The login.jsp and logout.jsp don’t go through the dispatch servlet, so they can’t use the message bundle for the window and page title.
There is way too much to this simple application to cover completely now, but I’ll give the highlights of what to go look at in the major configuration files. Paths are relative to the project root:
web/WEB-INF/web.xml- notice that I configure two dispatch servlets. One catching *.htm and one *.json. This sets things up to treat Ajax requests differently. Spring Security is also configured here.web/WEB-INF/applicationContext.xml– typical application context for a Spring application. I turn on annotation handling with package scanning under the sample.core package. Apache Tiles is configured in this file, and I have also configured a Transaction Manager around the JDBC DataSource. You should tweak this based on your underlying persistence preferences. I’m a RowMapper fan, but you can plug in Hibernate or JPA.web/WEB-INF/htmlDispatch-servlet.xml- the context for web (*.htm) requests. This sets up the ResourceBundle for messages and a typical ViewResolver mapping the *.htm requests to jsp files under web/WEB-INF/jsp. Also configures component scanning for the sample.web package.web/WEB-INF/jsonDispatch-servlet.xml– the context for Ajax (*.json) requests. Configures component scanning for the sample.json package and specifies a custom Ajax ViewResolver. This will automagically serialize all ModelMaps returned out of the Controller responded to *.json requests to JSON.web/WEB-INF/applicationContext-security.xml– so simple to look at, yet so painful to figure out. This is the Spring Security configuration file. Although it looks deceptively simple, it was a beating to figure it all out. It enables annotation-driven security, which you saw on the EchoService above. It also sets up the form login and locks down all the pages. Note I leave the /resource directory open. This is where I put all my javascript, stylesheets and images. If you want to secure those resources, you’ll need to get more specific on the intercept-urls.
Users are declared at the bottom. Passwords are clear text, which is fine for a trivial demo, but you would want to replace this with something more industrial-strength in a real application.web/WEB-INF/tiles-config.xml– the Apache Tiles configuration. I only setup one definition here to keep it simple.web/WEB-INF/jsp/layouts/baseLayout.jsp– the base layout used for tiles. I’m only inserting content at two locations in the template. In the HTML head section, I allow for an optional insert of headerContent. I use this to include JavaScripts specific to a page. The other content is within the center div called mainContent.
Note that the body is pretty empty and that the divs all have the x-hidden class. This means they are not normally visible. I use an ExtJS Viewport for layout, which uses the contents of these divs.web/resources/javascripts/layout.js– this JavaScript file was included in the baseLayout.jsp above. It creates the Viewport using a border layout.web/resources/javascripts/index.js– the JavaScript file included for the index.jsp page. It decorates the plain HTML inputs on the page to do the cool Ajax stuff. Note towards the bottom how I use ExtJS to set focus on a form field and to bind the ENTER key to the submit button.web/resources/javascripts/login.js– the JavaScript file use for the login.jsp page. If you look at login.jsp, you’ll notice there is no form. Everything is created by ExtJS from the login.js file, including the cool box effect. One trick is that Spring Security wants a normal form POST for the login form. I override the form to do a standard submit instead of an Ajax submit and set the form action explicitly.
This covers the major features. I’ll be using this as a base for other projects and will be expanding out my ExtJS demo. Since there are pretty much zero examples out there of tying together this stack, I hope this can be of use to some folks.
- 2/28/2009 – upgrade to ExtJS 2.2.1, fixed compile issue on Linux, added in iBatis for ORM
- 3/26/2009 – I’ve setup a dev server with the latest version of the template at CodeZombie.com so you can check it out without having to install. User scott/tiger for credentials. I’ll be updating this install with a more feature-rich demo application shortly
- 3/28/2009 – changed around the project structure and build.xml to use Ivy for dependency management. Check the README.txt file in the root directory for the details.
- 4/28/2009 – updated the included JSON encoder to be able to return JSON arrays by using the key
_rootin the model map. If this key is found, its content will be used as the root element of the return JSON instead of encoding the whole map. Also removed the unicode characters from StringScrubber to make the compiler on Linux happy.
p.s. this pulls together a lot of jars and pieces from different folks to build the demo. If you use this for more than playing around, you need to make sure you respect whatever licenses the authors have in place.






