Visual Web JSF and data: questions, considerations, thoughts

If you arrived at this blog post hoping to find answers you will be cursing me within the next 30 seconds. This is a post for questions and snarkicism. In evaluating Netbeans Visual Web JSF and Woodstock, I am now turning my attention to data.

This is a touchy issue with me. I am hard-core about separation of concerns. I’m like the kid who will NOT eat the macaroni and cheese if the spinach is touching it! I don’t want any data access code touching my presentation layer!!! NO TOUCHY! This is why I cannot use the primary data binding method in Netbeans: dragging a table to a data control. Sorry. Can’t do it. I did not bust my butt learning java only to return to Powerbuilder-style data binding. Yo! Shoutz to the Powerbuilder Datawindow!! You rocked the 90’s! The Datawindow was one of the greatest software components of all time! But the days of throwing data access, business logic, and presentation into one bucket are gone. Oh, and I’m sure I’ll hear from some of my Powerbuilder friends spouting off about how NVOs (Non-Visual Objects) and Stored Procedures solve these design issues (almost as lame as my Perl friends who spout off about just how Object-Oriented Perl is now…right, like a Perl programmer cares about object-oriented design)…but anyway…I don’t like the idea of binding database tables to GUI components.

Perhaps I’m misunderstanding this whole thing. Perhaps the DataProvider object does constitute a separation of concerns. Perhaps it also promotes reusability. Further research is necessary for me to determine this. All I know at the moment is that the database programmer/DBA wants to back this thing with Oracle Stored Procedures, and you can’t drag a Stored Procedure onto a control. You get three choices (as far as I can tell): Drag a Table, Drag a View, and Drag a Web Service. I don’t see JPA, Beans, EJB, or Stored Procedures. If you want to use those, I guess you need to give up the nifty drag n drop data binding features and code it your damn self!

The following Q&A from an Ask the Experts for Netbeans 6 is relevant to my post:


Michele Giuliano: I’m trying to convert my erp (written in Powerbuilder) in Java using NetBeans 5.5.1 and Visual Web Pack. I have used CachedRowSetXImpl and CachedRowSetDataProvider to manage the da develop with visual web pack. Is it right?


David Botterill: There are really lots of background questions that need to be asked to get the correct answer for this. But, given the information at hand, EJB is a better choice. If you are building an ERP, you will have lots of business logic that needs to live somewhere. If you go from a web client through the visual web dataproviders and CachedRowSet, you really only have a two-tier architecture, (client)-+-(data). In your case, you really need at least one other “middle” tier that contains the business logic for your system. The business logic is the value of your system and needs to be reusable and easily maintainable. This is the purpose for component-based architectures like EJB. You will thus have a (client)-+-(business logic)-+-(data) architecture. This allows you to change out the client while preserving your business logic. You CANNOT capture complex business logic like ERP in data access routines via dataproviders and CacheRowSet. Even the JSF backing beans will not really allow your business logic to remain autonomous since you’ll usually have framework-specific code living there. Another advantage of using this architecture is the ability to use something like Java Persistence API (JPA) on in the data tier and also this will allow you to expose your business logic via web services.

Perhaps I truly can’t bake my cake and eat it, too…at least not yet. This little nugget from the Architectural changes for Visual Web Next gives me hope for the future:

Data binding enhancements

Dataprovider is one of the main mechanism to bind data to the components. Eventhough, dataprovider is nothing but a thin API to support uniform way for the components and DesignTime System to interact, it can be consider proprietary, since it introduces “non standard” API with package name “*” in the source. It may be possible to hide the dataprovider, so that the user need not have to know about the dataprovider externally. This is already accomplished for table component.May in the future, we should

  • Promote Java Persistence API as the main data access mechanism
  • The DesignTime System must be able to bind collection of POJOs to components
  • When database table is drag and drop bind using JPA than CachedRowset
  • Complete designtime support to create Entity Bean and corresponding Controller for binding

Finally, we must get rid of the need for a live database connection even after the table is bound to the component. One solution for this is to use only JPA for binding. If Cachedrowset need to be supported for backward compatibility, then database schema should be persisted in the project for offline access later.

Let’s get busy with this one Netbeans!


  1. “I’m like the kid who will NOT eat the macaroni and cheese if the spinach is touching it!”

    That’s a strange irony, don’t you think?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s