On Feb 16, 2008, at 3:43 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?

I don't know of any such examples, since nobody has contributed

anything like that.

But to answer your question about complexity, there is no reason why

Dabo apps would ever have to be limited to simplistic designs.

Generally the rule is 1:1 bizobj:table, but there is no limit as to

the relations possible between bizobjs, nor the number of bizobjs that

can be involved in any given form.

> 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).

Well, sure, because that's the simplest example to whip up. Remember

that none of us are getting paid for this, so the tendency is to not

spend hours and hours trying to come up with an example that satisfies

everyone's possible usage for the framework.

> 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.

Of course, it depends on how the tables are related to each other. If

they are all related in some form of parent-child type of

relationship, then no additional work is needed by the developer:

calling save(), new(), delete() in the form will do pretty much what

you would expect. All of those calls take an optional DataSource

argument, so if you need to, say, add a record to a particular bizobj,

the call in the form is simply self.new("foo"), if 'foo' is the

DataSource of the bizobj in question.

If you have groups of bizobjs that are not related to each other, you

will have to handle some of the "glue" code yourself. Each form has a

PrimaryBizobj property that is the default recipient of all bizobj

commands, and that bizobj will take care of its child bizobjs, who

will take care of their child bizobjs, etc. But if you have unrelated

groups of bizobjs, you will have to write the code to decide when one

group is being called, or when the other one needs to be called, or

when both are involved. I can't be any more specific, as the code in

question depends on the particulars of your design. In general,

though, the code would look like this:

bizFoo = self.getBizobj("foo")

bizFoo.doSomething()

bizBar = self.getBizobj("bar")

myVal = bizBar.getFieldVal('myField")

-- Ed Leafe