Well before really starting, can I ask your thoughts on where DBForms is going?
Due to concerns of performance with big tables, it looks like classic will be kept, doesn't it?
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.
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".
Did the weather co-operate for you?
-- Shawn
Happily using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
------------------------------------------------------- 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
