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