Author: johnf
Posted: 2008-02-16 at 18:35:52
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]