as you know I've already done this, but now I've some doubts about it. Now we have a set of customizable events, and a set of data access systems. IMHO there is no need to have such a beast. Think about a table, the best way to define its behaviour is through an attribute that define the behaviour of the entire wholeset of events defined for the single table (as is now for data access configuration), it make little sense to define a navNext event of one type and navPrev of another (as you said below). In conclusion, my vision of dbform's future is to simplify the events structure, removing the event's type selection, and focalize the behaviour's changes in the data access pattern. But to make this we have to create an interface between events, on one side, and data access pattern, on the other, more solid than it is now. I take as example my adding of sqlFilter attribute. To add this attribute, that touch the way data is accessed, I have to change all interfaces of events package and data access package. If we could reorganize the way events "call" data access (and the way events are created) making it more abstract, i.e., more impermeable to such a changes, we'll have a lot of benefits. In conclusion, I think that the reorganization, to be effective, has to start from event, the way event are created, and the way event "talk" with data access pattern.
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...
This is an hard work, but in prospective, is the way to walk. For this reasons I regret about collapse "navigation" into datalist pattern.
But first we must understand how it works and maintance it. I remenber thatI'll try to document this.
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!!!!!!
cheers -- Sergio Moretti
------------------------------------------------------- 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
