-------------- Original message ---------------------- From: Ed Leafe <[EMAIL PROTECTED]> > On Dec 24, 2007, at 1:50 PM, Adrian Klaver wrote: > > >> No, that is simply wrong. You are mixing the UI DataSource with the > >> bizobj DataSource. Bizobjs do not have update(); that is for data- > >> bound UI controls. Likewise, UI controls don't have save() or > >> requery(). > > > > I beg to differ. > > > >> From the api doc for dForm > > > > save(self, dataSource=None) > > > > Ask the bizobj to commit its changes to the backend. > > A form is not a "control". Forms do not have DataSource or DataField > properties.
Yet when you do self.save() or self.requery() the 'Right Thing Happens' and the DataSource is updated or queried which makes it a data control in my book. We could spend more time going round on this, but I will go along with the explanation below and move on to other concerns. > > In the 3-tier design, the form is the sole interface between the UI > and the bizobj tiers. > > > You are making my point about confusion over the name DataSource. > > It refers to > > different things in different contexts. I am just trying to figure > > out when > > that context changes. > > In both cases (controls and bizobjs) it refers to the "source" of > its "data". Bizobj get their data from the table, while controls > (typically) get their data from the bizobj. In both cases it means > exactly the same thing; because they are in different tiers, though, > their sources are necessarily different. > Exactly. It is the transition of the bizobj 'source' that is not entirely clear to me. Having taken the time during the interlude to walk the dog and swamp out the truck, I have had a chance to ponder on my issues.Let me sketch out what I think I understand and where my understanding falls of the rails. First this based on using the full Dabo framework db-->bizobj-->ui 1) Create bizobj. Serves as 'template' for communicating with db and ui. Also serves as local data store. 2) Create ui form and controls. Actually this could happen before 1). Form elements can receive data from the bizobj as well as other sources 3) When requery() is called form afterInitAll the bizobj is populated with data from the DataSource i.e database table. The ui in turn uses this data to fill the data controls. At this point there are two versions of the data. One resident in the database table, the other resident in the form. For some time, albeit it possibly brief, they are the same. 4) Changes are made to the form resident data. update() is used to populate the form controls when navigating in the form. At this point the form data is different from the database data. 5) It is possible that changes have been made to the database table outside of the scope of the Dabo app. Again this means the db data and the form data have diverged. 6) When save() is run the changes in the form are propagated back to the database via the bizobj . requery() propagates changes in the db to the bizobj and hence to the ui. This is where I run into a problem. Problem: Open form with data. Make change in form field from Dabo app. Make committed change in same record but different field from outside app i.e. psql. From form do save(). Database has Dabo changed field updated. Do requery() , db is queried but non-Dabo change is not shown until an update() is done. Why? Shouldn't the requery() pull in all the new data. If point 3 is correct then the new form resident data should equal the db resident data after the requery(). -- Adrian Klaver [EMAIL PROTECTED] _______________________________________________ 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]
