Hi All ! In my opinion, changing the resultSet implementation is a big risk. *IF* I understood the problem (maybe not) and IF the requirement is:
- to have an interface to retrieve "jdbc-like" resultSets depending on the data currently managed by dbform's resultSetVector AND the problem is that: - the dbforms resultSetVector doesn't have much sense out of the dbforms core and / or is not easy to manage we could: - release the 1.1.3 FINAL Version (with docs and other additions discussed into the list) and then: start adding a "function" that could transform the computed dbforms resultSetVector into a more useful implementation - one having a better interface that can be used to handle data programmatically. Example: retrieve the current dbforms coordinates related to the underlying database table (first record currently showed, resultset size, query conditions, etc) and use them to return a collection of "bean-records" that can be easily managed by developers into their own applications. So: DbForms core does not change, but developers could have a better chance to collect data from the "current" logical resultSet. Time ago I did (with cut'n'paste ;^) an implementation of the data list handler pattern with JDBC2 (search pow2toolkit on sourceforge - should be pow2toolkit.sourceforge.net). The result was very good (IMHO): a bunch of simple and logical interfaces to deal with and a bunch of concrete classes that do the real work. As the pattern focuses on interfaces, it's easy to reimplement the data list with JDBC1.0 or with other data access systems. As a concrete example, it could be possible to make a factory that returns a data list handler class starting from the current DbForms resultSetVector... About the "fork option"... well, I can't say I love the actual resultSet management implementation, but I don't understand the whole thing, too. I'd like to see more internal documentation about the dbforms core (I started to work on this topic making some uml diagrams). Shawn and I asked for some help to Joachim and Philip without success; it seems that the original ideas about the navigation system were "lost" somewhere in the space ;^) Regards, Luca Henner Kollmann wrote:
Hi Shawn,
Back from holidays? Hope that it was nice.....
Before we change the resultsetvector we should release a stable version.
We have had some ideas but not a real implementation. Changing the resultsetvector is a lot of work - so the best would be to
work in a branch.
Do we find some people who will help us?
Regards,
Henner
------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
