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