Data Provider APIs -- A hidden gem in Creator 2 EA
As many of you know, Sun recently released Sun Java Studio Creator 2 EA, a product for which I am the Architect. By the way, yes that really is a shark -- Creator releases are code-named after various breeds of sharks, and this release is called "Thresher Shark". Anyone remember the code name for the previous release?
It's been quite pleasing to see all the positive response from users and the press (including the one my colleague Tor pointed out). Everybody comments on the nice new components, the refined look and feel, and all the new editing features (which we inherited by upgrading our base platform to NetBeans 4.1. But I haven't seen as much attention to one feature we added -- a new binding API for connecting components with back end data providers of various sorts. As we talk more about what these APIs do, a quick sidetrack into how we got here might also be of interest.
Even back to its origins as a skunkworks effort called "Project Rave", Creator has been focused on empowering an audience (corporate developers) that has, in many respects, found the Java platform difficult to deal with. Besides liking to use component oriented development, and drag-n-drop tools, one of the application styles that corporate developers tend to spend a lot of their time working on is retrieving data from databases, and displaying it in tabular reports. "OK", we said, "let's make this really easy -- just drag a database table from the Server Navigator, drop it on the Table component, and the component should automatically adapt to the columns that are available in the query."
We accomplished that initial goal, and this feature quickly became one of the most popular capabilities in the original release. But we quickly started hearing customer feedback that there's more ways to access data than just JDBC based rowsets. And, anyone who used the visual binding capabilities for rowsets would quickly ask for the same thing when they want to bind to the return value from a web service (or EJB) method call, or have a data abstraction layer that presents the persistent data as a set of JavaBeans (for example, if you're using Hibernate underneath). Could we, pretty please, hook up the same sort of drag-n-drop binding, and customization of the resulting table structure, for these data sources as well?
So, we did. I got the chance to demo this in public for the first time during our JavaOne session, "What's New With Sun Java Studio Creator" (TS-6911). When I got to the part about data providers, I did the following demo:
- Dragged a Table component onto the design surface.
- On the Server Navigator, I expanded the node for my demo database, and dragged a database table onto the page, dropping it on the table component.
- The design time API for the Table component took over, and created a
CachedRowSetinstance to interact with the database, plus a CachedRowSetTableDataProvider to interact with it abstractly. - In addition, the Table Component dynamically recreated its columns, matching the columns returned by an SQL SELECT statement. Because Creator asks the components to render themselves, even at design time, you immediately see how this is going to look.
- This much we could do before. But the next step was new -- I expanded a node representing a particular Session EJB that was installed on my server, and dragged the getCustomers() method (one of the public methods provided by this particular EJB) onto the Table component.
- This time, the design time code synthesized and compiled a custom TableDataProvider for that particular EJB method, and wired it up to the columns of the table, which now matched the bean properties of the Customer beans returned by the method.
- Changing my mind again, I did the same thing, but this time with the results returned by a web service call.
- And again, a custom TableDataProvider was constructed for me, the columns were changed to match the new result type, and again we see the result immediately.
- For my last trick, I used one of the concrete DataProvider implementations we ship with Creator (ObjectArrayDataProvider), dropping it on the design surface and using the property sheet to connect it to an array of JavaBeans that my application provided. Then, I used the Table Layout customizer to bind the Table component to this data provider, instead of any of the others (you can certainly have more than one data provider in use on the same page, if you need to). Again, the Table component adapted itself, this time to the bean properties of my existing bean class.
- In none of the cases above did I even have to write any Java code to actually retrieve the data. The data provider implementations take care of that for you, the first time the component asks for some data. It just works.
I've been speaking at conferences and in front of customers and user groups for over six years, but what happened next is unique in my experience -- I was interrupted by applause for a technical feature of a product that I had had a hand in designing and building. Way cool. But what's even cooler is that the developers in the audience recognized how powerful this abstraction is, and how easy it can be to build applications accessing any source of data.
So, when you grab a copy of the Creator 2 EA release (you can get it for free, just follow the download link), I would encourage you to not just stop at the comprehensive palette of JavaServer Faces components. Open up the "Data Providers" and "Advanced Data Providers" categories, and drag a few onto the design surface. See how you can use the same visual editing experience to compose applications from non-visual components as you do with visual components. Open up the JavaDocs ("Data Provider Reference" in the dynamic help window") and explore how you can leverage these APIs in your application code, as well as the use Creator puts them to for binding. Give us some feedback on to make this aspect of Creator, along with everything else, even better in the final release.
And, the next time you read a review of Creator 2 EA, look for some comments about data providers :-).

Posted by Will Iverson on August 12, 2005 at 10:24 PM PDT #
At the moment, the Data Provider APIs are under the same licensing sceanrio as the reat of the EA release ... the whole thing is "for evaluation only, not appropriate for productin." However, we are listening very carefully for VOC ("voice of the customer") input on what the license terms for the final release should be. If you think (like I do :-) that this API should be broadly opened up, please register for the Creator 2 EA release, and contribute your thoughts on what <strong>you</strong> would recommend. On this particular topic, though, I can personally assure you that you wouldn't be alone in advocating very liberal licensing terms :-).
Posted by Craig McClanahan on August 13, 2005 at 12:43 AM PDT #
Posted by Craig McClanahan on August 13, 2005 at 12:47 AM PDT #
Posted by Brandon Werner on August 14, 2005 at 10:02 AM PDT #
Posted by Jacob Pays on August 15, 2005 at 08:39 AM PDT #
Posted by Dev Brown on August 15, 2005 at 09:01 AM PDT #
ui:staticText id="staticText2" text="#{currentRow.value.first}"Removed outer angle brackets to get posted...Posted by Dev Brown on August 15, 2005 at 09:04 AM PDT #
The key to success is to <strong>first</strong> create a property on your page bean, or on RequestBean1/SessionBean1/ApplicationBean1, that returns an array of some object type. (Yes, that's a restriction. Yes, we're aware of it and are looking at it). This will cause the property to appear in the dropdown list for the "array" property on the ObjectArrayDataProvider component. The alternative approach is to programmatically set this configuration, in the constructor of the page bean. That's what happens when you use the property sheet -- you end up with a statement like this in the constructor (assuming you have a "customers" property on RequestBean1 just to make the example concrete):
objectArrayDataProvider1.setArray((Object[]) getValue("#{RequestBean1.customers}"));For further assistance, your best bet is to post a question on the forum that is dedicated to Creator 2 EA feedback, available via the URL I posted in the original blog entry.
Posted by Craig McClanahan on August 15, 2005 at 11:04 PM PDT #