Forms and Querying

[scottr]

Hi all,

I am fairly new to Spring RCP, and its taken a while to bring myself up to speed on how it all fits together. I am impressed by what I see - it is clear that a lot of work has gone into making a sophisticated client-side framework.

One thing I found lacking was an approach to querying data sources for domain objects. By that I don't mean a data-access layer API such as what exists in the main Spring branch, but more of a stronger, domain-oriented query API.

My thoughts on this are that Spring-RCP could benefit from the definition of a query API similar to eg. Hibernate's Criteria API, but with a focus closer to the view or the domain model than the data-access layer. That is to say, it would be an object-oriented model of a query that allows one to express constraints on domain properties and paths.

But how to go about it? Some initial suggestions are:

1) A QueryModel interface (similar to or extending FormModel ?) bound to a type (ie. a domain class), with an abstract implementation for JavaBeans.

2) Support for setting constraints upon that QueryModel, conceptually similar to constraints in traditional query languages like SQL or XPath, (this would re-use the existing Constraints and Rules API).

3) (Abstract) methods within the QueryModel to invoke the query (how this is handled will be up to the developer), and returning an ObservableList or a PageableList. The latter would retain a reference to the QueryModel and invoke it upon 'next page' or 'previous page' commands.

3) Translation classes within the main Spring branch to convert such a QueryModel (or its set of constraints) into the query APIs of the different ORMs (or JDBC) supported by Spring. I have already mentioned Hibernate's Criteria API, and I presume similar concepts exist within JDO, OJB, etc.

If anyone has any thoughts on this I would be interested to hear them.

regards,
Scott Russell

[adepue]

I've been thinking along similar lines lately as well. We have implemented a "distributed model" in our architecture: a client can query domain objects and then operate directly against those objects. Mutations to the objects are sent back to the server, who persists the changes and broadcasts those changes to everyone participating in the distributed model. A service on the client side then asynchronously updates the local copy of the distributed object(s) and notifies any local listeners of the update. This works well, but we have put together a quick and dirty (aka, crude) implementation for the "query domain objects" part of the picture. In reality there are multiple components involved: JMS is used to transmit mutation requests and events while Hibernate is used for persistance on the server side. To optimize communication between client and server there are two queries that must be setup: a Hibernate query to initially populate the local model and a JMS query to filter mutation events so that the local client doesn't receive events for objects that it doesn't currently have a copy of. Your solution would be perfect as I could define the query once via the QueryModel and then translate it into the JMS selector syntax on the one hand and Hibernate Criteria on the other.

- Andy

[pdbruycker]

Recently I created a "generic" query view for use with spring rcp (it lets you define a searchbar very easily, and there's support for advanced query building). A formal QueryModel definition would greatly enhance the stuff I wrote.

I'll try to post it as soon as I can.

[scottr]

Recently I created a "generic" query view for use with spring rcp (it lets you define a searchbar very easily, and there's support for advanced query building). A formal QueryModel definition would greatly enhance the stuff I wrote.

I'll try to post it as soon as I can.

I would be interested in seeing that, as it might give me some ideas how to structure the QueryModel.

-Scott

[ThomasCorbin]

Recently I created a "generic" query view for use with spring rcp (it lets you define a searchbar very easily, and there's support for advanced query building). A formal QueryModel definition would greatly enhance the stuff I wrote.

I'll try to post it as soon as I can.

I would be interested in seeing that, as it might give me some ideas how to structure the QueryModel.

-Scott

Yes, that sounds wonderful, thanks!

-Tom