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
_______________________________________________
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]
