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