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