Hi Christopher: I think that the point they tried to show us is that the database functions can be an optional part of all the Flow block. I agree because some applications will not need to use databases at all.
>From my point of view (I hope the same as you) the added database functionality now is just experimental. Teh Database API try to interact directly with the Database if someone does not like (or want) to use Beans. This is the main reason why it is currently mixed with the main behavior, it is just an experiment. In the future there will be a library or an object that you can include if you need DB API functions with Flow. Attached is a PNG file that show my point of view of the big picture of how Flow work with XForms and Databases. I hope I am not wrong. :) This is the Framework I see to build web based Database Aplication: The Flow Controller controls every XForm set. There can be 1 XForm set for each object. ie: Customers, Providers, Invoices. Every XForm set can have more than 1 XForm page. For example, we can have 1 XForm to add a new customer, 1 XForm to edit a customer, another XForm to delete customer, etc. (I think that we can build a XForm set that can interact with a concretly every Application Object). The glue between this XForms is the Flow Controller. In the graph I also showed that every XForm can be attached to a Bean. There are also cases when 2 or more XForms can be attached to the same Bean. The Beans describe the fields that the XForm show to the user. The Bean has the same fields as the XForm. In this point I feel like we can use another approach. Because I looks like the same fields need to be writen 2 times: In the XForm itself and into the Bean. :-( Then there is a O/R map (can be Hibernate, Apache Jakarta OJB. Modular Database Actions offer something similar too.). On the other hand the Database API can be usefull to get some stuff directly form the Database. Best Regards, Antonio Gallardo.
<<attachment: Flow.png>>
