In a message dated 8/12/2009 10:14:43 A.M. Eastern Daylight Time, [email protected] writes:
> 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. This sounds interesting... What's the constructor, and how does one pass bizobj objects through it? > 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. In other words, the modules change little, but since they do change, you still have to validate them? Jonathan --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ 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]
