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 CachedRowSet instance 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 :-).


Hi Craig! What's the licensing terms for the Data Provider stuff?

Posted by Will Iverson on August 12, 2005 at 03: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 12, 2005 at 05:43 PM PDT #

Preview mode for comments? Nah ... don't need 'em. :-). PLease read "as the REAL of the EA release" as "as the REST of the EA release", which is what I really meant.

Posted by Craig McClanahan on August 12, 2005 at 05:47 PM PDT #

Excellent! Now I can add to my "interview" RSS feed more than just Tor.

Posted by Brandon Werner on August 14, 2005 at 03:02 AM PDT #

Hi Craig, I've dropped an ObjectArrayDataProvider and am trying to connect it to an array via the Property Sheet method. But the array property drop down contains no entries and doesn't allow me to type anything in. How did you get this to work?

Posted by Jacob Pays on August 15, 2005 at 01:39 AM PDT #

Craig, could you please send me a code sample of how to use the data providers with the new Creator EA table? For testing, I created a simple bean that has two fields, firstName and lastName. In the getter for the ObjectListDataProvider that the TableRowGroup's sourceData attribute is bound to, I create a list of 9 of these objects, then call setList on the ObjectListDataProvider instance. In the JSP I try to reference it like so: <ui:staticText id="staticText2" text="#{currentRow.value.firstName}"/> Sometimes it does not show up at all, other times it shows up, but then when I click the sort button, I get a NPE. If you could send me a simple example how to use these properly, I would be very grateful. Thanks!

Posted by Dev Brown on August 15, 2005 at 02:01 AM PDT #

In the JSP like so:
ui:staticText id="staticText2" text="#{currentRow.value.first}"
Removed outer angle brackets to get posted...

Posted by Dev Brown on August 15, 2005 at 02:04 AM PDT #

Craig, could you please send me a code sample of how to use the data providers with the new Creator EA table?

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 04:04 PM PDT #

Post a Comment:
Comments are closed for this entry.



« January 2017