On Wednesday 26 December 2007 11:39 am, Ed Leafe wrote: > On Dec 26, 2007, at 1:09 PM, Adrian Klaver wrote: > > If my outline above is remotely correct the relationship between > > the Dabo.biz > > and Dabo.ui layer is one sided. In other words the ui layer does > > most of the > > work by pulling and pushing data from and to the biz layer. This is > > where my > > understanding fell down. > > It is no more one-sided than the relationship between the bizobj > layer and the database layer: the bizobj pulls and pushes from/to > that layer just as the UI does with the bizobj. > > Bizobjs exist without any knowledge of UIs. The same bizobj can work > with a wxPython UI, a web interface, a command line program, etc. > They simply expose a few methods and properties, and return the > desired information.
See comment below. > > > Obviously I misinterpreted the information presented on > > the Dabo home page as ascribing more power to bizobjs with regard > > to interacting > > with the ui layer then is the case. > > > > "Business Rules > > This tier is where all the business logic resides. You simply > > subclass dBizobj, > > set a few properties, and override a few methods. The dBizobj > > communicates with > > the database tier and the user interface tier, and enforces your > > business rules > > to your specifications. > > I don't see anything incorrect or misleading there. Can you be more > specific about what you find confusing or misleading? "The dBizobj communicates with the database tier and the user interface tier .." The reality is that dBizobj communicates(push/pulls) with the database tier and the user interface communicates(push/pulls) with dBizobj per your explanation of the one sided nature of the communication above. The bizobj resides in the middle but does not really serve as a communication mediator between the database layer and the user layer as is implied by the sentence quoted above. If a bizobj really communicated with the ui then bizobj.requery() would update the form elements. > > > User Interface > > You create your forms by laying out various controls or widgets, > > and setting > > properties to tell Dabo what bizobj and what field in the dataset > > the control > > represents. There is no business logic at this level, and only > > minimal code will > > be entered here: it is mostly laying out your UI design and setting > > properties > > to tell Dabo how to connect to the business rules. " > > Again, that is exactly how programming should work in Dabo. Understood, though I think it might be clearer to add that the ui layer drives the data transfer from and to the business rules. The "connect to" statement implies a more passive role than is the case. > > > I would like to ask that the documentation for the form versions of > > save() and > > requery() be changed to reflect that they do more then simply ask > > the bizobj to > > carry out the same operation. > > Could you suggest alternate wording for the docstrings in question? save(self, dataSource=None) Ask the bizobj to commit its changes to the backend. "How form.save() behaves is completely under your control. There is a property of the form named 'SaveAllRows'; its default value is True. When True, calling form.save() results in a call to bizobj.saveAll(), which saves all changes rows; when SaveAllRows is False, calling form.save() results in a call to bizobj.save(), which will save the current row if it has pending changes." requery(self, dataSource=None) Ask the bizobj to requery. Also calls form.update() to make the changes visible in the form controls. > > -- Ed Leafe > -- http://leafe.com > -- http://dabodev.com > > > > [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]
