Hi Shawn, Sorry for answerings so late, i was sick the last days - some sort of virus infection..
> Well before really starting, can I ask your thoughts on where > DBForms is > going? Here are my .02 thoughts.. > > Due to concerns of performance with big tables, it looks like It's not a performance problem - just a memory problem with the handling of big tables. > classic will > be kept, doesn't it? I think we should keep it if we understand how it works. The class structure is well documented now, but the way how the next record is found through sql statements is unknown... If you look at the resulting sql statements it looks mystic if you have more then one key field. I do not understand this part! > > > Sergio also suggested either to: > > A) reorganize to better fit classic versus others: the way > we've walked > 'til now > > B) try to reengineer classic, removing that code from Table > class and fit > it in a way like datalist do. This may have many benefits, > since classic is > very coupled with other codes. Obviously we need deep > informations on how > it work. So I agree with Luca's works about documentation. Cleanup of code is everytime a good idea. The whole framework is old and grown - refactoring is ok and makes it clearer. > > Which way seems the most likely to you? Also, if the new > sqlFilter works > as advertised, it seems like we could get rid of the > whereClause and filter > attributes, doesn't it? My question is then, do we really need > documentation on that aspect of the classic system? It seems > to me like > option B would be desirable long term as it would simplify > understanding > DBForms since the different navigation systems wouldn't be so > different and > the de-coupled Classic (not buried in Table) would be easier > to understand. > > Also, if B is chosen, I suggest that we call it "renaissance". If we understand how classic navigation works so that we can maintance we should intergrate it into the listClasses structure. Sergio suggested this once. I think the using is much simpler then using the navigation system. You must only change one attribute use it, not a bundle of navigation events... But first we must understand how it works and maintance it. I remenber that there a some mystic problems to find always the right set of records. Also the genereted sql is not very effectiv if you have more then one key field. This will result in a repeated and/or sequence for each of the key fields where each field is listed more then once. Luca tried to get information from the original developers, but we do not get any responce. I think, this know how is lost in space. Maybe Sergio has a change to understand and document? I would be happy!!!!!! In the next time i would like to spend some time to bug fixing the currenct release, add some new ui features and bring out the 1.4 release version. I would like to add some more xml features. > > Did the weather co-operate for you? Yes, thanks!! Regards, Henner ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
