I think that we should focus on rdbms and jdbc layer, and it's a hard work to develop a new language to map either sql o xpath, and, on the other end, a filter to be effective, has to be as tight as possible to the engine, so you you are using a xml dataset, you have to use a xpath filter, if you use a jdbc engine, you have to use a sql filter. An abstraction layer is not worth here.So I think another step could be to use standard SQL to specify "all type of filters". Having only whereClause and orderBy attributes could be the best thing to obtain. Having another (redundant) attribute is not a good idea, IMHO.
Problem with pure SQL i see is that you can only use rdbms with sql. No
other forms of data like xml data.
I think we can have both, since this is already here, but if I have to choose only one, I'll take the raw sql filter.
rdbms engine, without spending hours to debug a new
"condition-meta-language".
The problem is that DbForms original engine is built around this concept -
it
uses a "cumulation of rules" to build a final SQL statement. Ah, yes, you know ;^)
One of the benefits of this concept is that you can map the
"condition-meta-language" easily to other datasources.
Of course, original rules are quite difficult to understand because thy try
to build an sql statement to get only the needed data. If we through away
claasic navigation we can make the "cumulation of rules" much easier to
understand.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ DbForms Mailing List
http://www.wap-force.net/dbforms
