On Saturday 16 February 2008 02:44:46 pm Michael Hipp wrote: > johnf wrote: > > On Saturday 16 February 2008 01:43:12 pm Michael Hipp wrote: > >> How does the UI, bizobj and database layer in Dabo cope with screens, > >> business rules and database queries that span multiple tables and > >> records? Can anyone point me to some example code that shows how Dabo > >> handles this? > >> > >> Lots of "models" appear to be somewhat cast in what I call the 1:1:1 > >> syndrome (i.e. each screen holds one record from one table that is > >> governed by one set of business logic). > >> > >> How do the layers of dabo handle the (frequent) case where one screen > >> may have fields (hidden or otherwise) that span multiple tables, thereby > >> spanning multiple sets of business logic and so on. > >> > >> ... probably clear as mud ... > >> > >> Thanks, > >> Michael > > > > Right clear as mud! > > I think what you are saying is how does Dabo deal with one to many data > > setups. Great! To my knowledge there is no limit on the number of child > > tables a parent can have. What ever you can setup using SQL I'm sure > > Dabo can handle. > > > > I have several forms that have many children (or a relationship I create > > using SQL) which means I have many different fields from different tables > > on my forms. On the same forms I use tables (lookups, meta data, > > combobox source) that I use to supply the data that are not children of > > the parent. > > > > Hidden fields? I think you mean fields that are not displayed on the > > screen. All the fields are available that you define. Dabo even has a > > virtual field that can be defined. > > > > Business logic? Do you mean can Dabo validate input - yes. If you mean > > will Dabo determine some special need (like if I add "A" there has to a > > "B" and "C" that exist) you most likely will require that you write > > special code. Of course if you can define it in the database - that's > > always better. > > Thanks, John. > > I believe you answered my question. But just to make sure... > > The problem with a lot of frameworks is that they have wonderful save() > and load() methods and such. But as soon as save() needs to work on > multiple tables (or even multiple records at one time within one table) > then all of a sudden the built-in helpers are no help and you're back to > writing fully custom SQL and managing transactions and such as if there > was no framework at all. > > Knowing that lots of my stuff is just like this, will I be glad I'm in > Dabo or will it seem like I'm just back to making calls to psycopg2 on > my own? > > Thanks, > Michael
Dabo saves all your changes including children fields. That said there will always be situations where you will have to code something. For example, I have a special virtual field that provides information on changes that could effect other tables not part of my form. I have to write code that will update those tables. I choose the do it that way because it doesn't happen often. I could have added them to the form and had Dabo handle it. I don't mind answering your questions. But how about telling us what you have in mind for Dabo. I think we will be honest enough to tell if Dabo will work. -- John Fabiani _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
