On Tue, Aug 11, 2009 at 23:54, Ed Leafe<[email protected]> wrote: > There are probably a few other ways, too. But the important thing is > your design is flexible enough for your needs. > > The first design puts the parent in control; the child doesn't need > to know anything about the parent. This means that the child dialog > will not be tightly coupled to the calling form, and allows for re- > use; it is the preferred method for creating generic components. The > latter two approaches have varying degrees of coupling between the > dialog and the form (in #2) and the bizobjs (#3). If the dialog is > single-purpose, then this coupling is not much of an issue.
I agree on the control. I tend to favor #3 the most but tend to decouple by passing the appropriate bizobj objects into the dialog through the constructor. My thoughts on this are that my models for standard things like customers and orders tend to vary very little, so I can use this approach without sacrificing modularity and still take advantage of Dabo's built in UI to biz layer connection properties (DataSource and DataField). Validation is the only sticky part of the dialog for me at this point. Regards, Nate _______________________________________________ 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/[email protected]
