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

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.

--

John Fabiani

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

-------------- Original message ----------------------

From: Michael Hipp <Michael@Hipp.com>

<Snip>

>

> 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

>

I good place to start is:

http://paul.dabodev.com/doc/api/dabodoc/

Look at the section on dBizobj and methods save() and saveAll(). I found it instructive to look at the corresponding code in ~/dabo/biz/dBizobj.py. I think you will find the Framework does what you want.

--

Adrian Klaver

aklaver@comcast.net

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

johnf wrote:

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

Thanks. And no problem.

The application I'm (re) writing automates an auction house. In simplest

form we have tables sorta like this:

customer /* List of pre-approved businesses we hope will buy stuff.

reps /* The individual buyers from the customer companies

widgets /* List of specific items we hope they will buy

transactions /* List of items bought, fees attached, misc charges,

payments made, etc.

history /* Old transactions and widgets already finished but needed

for historical reference.

performance /* Statistical information about who bought what, when,

price ranges, fees earned, best sellers, etc.

Auction houses like this one are peculiar because they operate only once

a week and have a whole 2 hours to make an entire week's worth of

revenue. The database gets lots of hits in a short time and any problems

are an instant crisis.

So a typical scenario is:

- Clerk calls up record for widget #302

- Auctioneer sells it to bidder #103 which is actually rep #8 from

customer #2091

- Along with saving the (now sold) widget record, we enter

transactions for the purchase price and programatic fees, enter

stuff in the reps and customer database as well as performance.

4-5 tables might be hit at once from the editing of one field from

one table.

- Later when bidder wants to check out he makes payment (more

transactions. - OR -

- Bidder somehow needs to cancel that purchase and the whole thing

must be unwound some hours later

That's a smattering. Certainly not "enterprise" class. But plenty of

places to screw up. And I'm pretty sure I found a lot of them. ;-)

The original version was pure wxPython with my own homegrown MVC style

and psycopg2 into PostgreSQL and a Linux server. All the pieces worked

great. But every time someone wanted a new screen or a new report or

just some modifications to an existing screen I wanted to go run and

hide somewhere because I couldn't maintain it all if I had a whole

platoon of programmers. So I'm looking for some "help" in the form of

code I don't have to write.

I think I've settled on a mix of Dabo and Django with a common db layer

(what many would call the "model"). I haven't entirely given up on doing

it all in Django but the more I look at JavaScript libraries the more my

head hurts. But certain things *need* to be on the web (for customer

access) so, in that sense, it's not an option to only use Dabo.

Any thoughts appreciated.

Michael

On Saturday 16 February 2008 03:24:55 pm Michael Hipp wrote:

> johnf wrote:

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

>

> Thanks. And no problem.

>

> The application I'm (re) writing automates an auction house. In simplest

> form we have tables sorta like this:

>

> customer /* List of pre-approved businesses we hope will buy stuff.

> reps /* The individual buyers from the customer companies

> widgets /* List of specific items we hope they will buy

> transactions /* List of items bought, fees attached, misc charges,

> payments made, etc.

> history /* Old transactions and widgets already finished but needed

> for historical reference.

> performance /* Statistical information about who bought what, when,

> price ranges, fees earned, best sellers, etc.

>

> Auction houses like this one are peculiar because they operate only once

> a week and have a whole 2 hours to make an entire week's worth of

> revenue. The database gets lots of hits in a short time and any problems

> are an instant crisis.

>

> So a typical scenario is:

> - Clerk calls up record for widget #302

> - Auctioneer sells it to bidder #103 which is actually rep #8 from

> customer #2091

> - Along with saving the (now sold) widget record, we enter

> transactions for the purchase price and programatic fees, enter

> stuff in the reps and customer database as well as performance.

> 4-5 tables might be hit at once from the editing of one field from

> one table.

> - Later when bidder wants to check out he makes payment (more

> transactions. - OR -

> - Bidder somehow needs to cancel that purchase and the whole thing

> must be unwound some hours later

>

> That's a smattering. Certainly not "enterprise" class. But plenty of

> places to screw up. And I'm pretty sure I found a lot of them. ;-)

>

> The original version was pure wxPython with my own homegrown MVC style

> and psycopg2 into PostgreSQL and a Linux server. All the pieces worked

> great. But every time someone wanted a new screen or a new report or

> just some modifications to an existing screen I wanted to go run and

> hide somewhere because I couldn't maintain it all if I had a whole

> platoon of programmers. So I'm looking for some "help" in the form of

> code I don't have to write.

>

> I think I've settled on a mix of Dabo and Django with a common db layer

> (what many would call the "model"). I haven't entirely given up on doing

> it all in Django but the more I look at JavaScript libraries the more my

> head hurts. But certain things *need* to be on the web (for customer

> access) so, in that sense, it's not an option to only use Dabo.

>

> Any thoughts appreciated.

>

> Michael

>

>

>

[excessive quoting removed by server]

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

Ed Leafe wrote:

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

[snip]

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

Thank you. I think I'm beginning to have some grasp of where bizobjs fit in.

Michael

On Feb 16, 2008 4:24 PM, Michael Hipp <Michael@hipp.com> wrote:

> The application I'm (re) writing automates an auction house. In simplest

> form we have tables sorta like this:

>

> customer /* List of pre-approved businesses we hope will buy stuff.

> reps /* The individual buyers from the customer companies

> widgets /* List of specific items we hope they will buy

> transactions /* List of items bought, fees attached, misc charges,

> payments made, etc.

> history /* Old transactions and widgets already finished but needed

> for historical reference.

> performance /* Statistical information about who bought what, when,

> price ranges, fees earned, best sellers, etc.

>

> Auction houses like this one are peculiar because they operate only once

> a week and have a whole 2 hours to make an entire week's worth of

> revenue. The database gets lots of hits in a short time and any problems

> are an instant crisis.

>

> So a typical scenario is:

> - Clerk calls up record for widget #302

> - Auctioneer sells it to bidder #103 which is actually rep #8 from

> customer #2091

> - Along with saving the (now sold) widget record, we enter

> transactions for the purchase price and programatic fees, enter

> stuff in the reps and customer database as well as performance.

> 4-5 tables might be hit at once from the editing of one field from

> one table.

> - Later when bidder wants to check out he makes payment (more

> transactions. - OR -

> - Bidder somehow needs to cancel that purchase and the whole thing

> must be unwound some hours later

>

> That's a smattering. Certainly not "enterprise" class. But plenty of

> places to screw up. And I'm pretty sure I found a lot of them. ;-)

Dabo can DEFINITELY handle this. As I understand it John has a lot

more complicated forms and he is running just fine. I have forms that

are about as complicated as yours and they run without a hitch. The

multiple bizobj transactions are not a problem at all.

>

> The original version was pure wxPython with my own homegrown MVC style

> and psycopg2 into PostgreSQL and a Linux server. All the pieces worked

> great. But every time someone wanted a new screen or a new report or

> just some modifications to an existing screen I wanted to go run and

> hide somewhere because I couldn't maintain it all if I had a whole

> platoon of programmers. So I'm looking for some "help" in the form of

> code I don't have to write.

I know that feeling...I used to be a wxPython programmer before

Dabo...You'll find that the Dabo code is about 5-10X smaller, even

more than that if you were rolling the db stuff as well....

>

> I think I've settled on a mix of Dabo and Django with a common db layer

> (what many would call the "model"). I haven't entirely given up on doing

> it all in Django but the more I look at JavaScript libraries the more my

> head hurts. But certain things *need* to be on the web (for customer

> access) so, in that sense, it's not an option to only use Dabo.

>

Have you tried cherryPy? That might be the better way to go if all

you need is to display purchase info to a customer. Also, you should

check out mod_python for apache and see if that would fit your needs.

Either way, using dabo in conjunction with YAWF shouldn't be a

problem.

Cheers,

Nate L.