[p27939]

I think we're finally at the crux of the issue. I'm not using hibernate and I don't plan on using hibernate. So this sample project is appropriate from that perspective. This sample project error-ed out with a 404 even when I had a real bean class in there. So the problem is that it's looking for the hibernate configuration and one is not there.

The documentation says that I can generate a ds.xml from Java Beans, which is what I'm trying to do. The visual builder can successfully generate a ds.xml from a Java Bean from this project without any hibernate configuration.

I must be missing something conceptually, why does a project have to have hibernate configured to use the Batch DataSource Generator?

Thanks.

[Isomorphic]

The comment you found in the source is a little misleading in that it means JPA POJOs. Again, in the QuickStart Guide we explain how to derive DataSources on the fly from true POJOs (no Hibernate/JPA) by setting just one property. If your use case doesn't call for Batch DataSource Generator, there's no point troubleshooting further.

[p27939]

Maybe you can help inform me of my situation. Technically, I have one business object, however, it’s pretty complex. It’s comprised of 32 bean classes with varying levels of composition and inheritance. The examples I’ve seen are pretty flat and simple (i.e. primitive types with no composition). So does that mean that I have one DataSource or do I have 32? If I have 32, then that is why I’m looking at the batch data source generator.

[Isomorphic]

What you need to consider is how much of that complexity you want to project into the browser and the UI. Most likely you have things factored into a bunch of separate beans for reuse and housekeeping purposes but there are only a few different entities in the UI and/or the end user's cognitive model of the data. Those are the ones where you want DataSources, the rest are details which need only exist server-side.

[p27939]

So just to be clear then, it sounds like I need to implement a custom DataSource class, to be run on the server-side, that understands my application's data model and have multiple DataSource descriptors (ds.xml) that only expose the part of the data model that is necessary to populate data-bound components.

Does that sounds right?

Also, can you point me to an example for a complex DataSource descriptor that does some composition and inheritance?

[Isomorphic]

No, that's not correct - you could, for example, have a leaf POJO that is mapped to JPA with various superclasses that exist only for server-side housekeeping purposes. In that case you might use a stock JPADataSource for this leaf POJO and never create DataSources for it's superclasses.

Likewise, we don't have examples of inheritance because "inheritance" is very rarely a word in an end user's vocabulary, so it's not typically part of the model as projected into the browser.

For "composition" substitute "relation" - the EE Showcase has examples of the core types of relation with JPA (1-many, many-many).

[p27939]

Let me try to be a little more specific to make sure that I get it or not. (probably not).

The entire back-end system that I'm connecting to has a custom REST interface that I'm not able to change. Therefore I don't believe that I can use any of the stock connectors. Which would leave me to implement a custom DataSource class for the server, right? (to marshall/unmarshall etc...)

I would then write 1 (or more) DataSource descriptors (on the client side) that would define the data that I want to expose to the end user and bind to components.

Now does that sound right?

Thanks.

[Isomorphic]

Ah, it would have been great to know that REST was the situation, which changes a lot. But now we're not sure of the architecture at all here.. are these REST APIs between the browser and the server? If so, then why are you looking at the JPA entities at all? You're binding to the REST services, so the JPA information would seem to be rather different. Presumably the REST services do not, for example, involve any information about inheritance.

Also, carefully consider this FAQ which talks about why pre-existing REST interfaces are usually inadequate for the needs of a UI, and consider whether you're really really locked into these interfaces.

[p27939]

Let's just say that the custom REST interface that I'm connecting to is in the cloud and I can't modify it. It'll produce some XML, defined by XSD, which I'll have the generated beans for so that I can easily marshall and unmarshall the XML.

I was thinking that we'd like to take advantage of the SmartGWT Java Server framework. It sounds like I would just treat this interface as just a custom persistence framework and implement a custom data source within the Java Server Framework. That way I can take advantage of many of the benefits that a Smart client has by relying on the Smart server.

[Isomorphic]

Ah, so you are calling a REST service from the server, and the POJOs were generated from the REST interface.

Yes, this is an example of a Custom DataSource and it does make sense to use the server framework. You will probably want the DataSources you expose to the browser to be simpler that the POJOs generated from the XML REST service (since you mentioned 32 POJOs, which seems like a lot for one logical business object).

A key server-side API you can use to populate these POJOs in DataSource.setProperties() / getProperties() as well as dataSourceField.valueXPath.