Ed Leafe wrote: > On Jul 8, 2008, at 1:48 PM, Paul McNett wrote: > >> It really just depends on the paradigm you want to use. Form-based >> makes >> a lot of sense, I'm not disparaging it. However, I tend to build at >> the >> panel- or control- level and have very little code at the form >> level. I >> like being more encapsulated and modular. >> >> The control doesn't "know about the bizobj" in my example, it merely >> knows that the form will know what to do. > > > In that case, something like "self.Picture = > self.Form.getMyPicture()" would be more appropriate. Forms are the > mediators between the UI and biz layers; controls should not bypass > the form's mediation.
We'll have to agree to disagree. I don't see a problem with a control asking the form for the bizobj reference and then asking the bizobj for information directly, especially since it results in a more flexible, modular, and encapsulated design (the form doesn't need to know anything about the sub-objects it hosts). The controls already update() and flush() to the bizobj directly, not through the form, because that makes the most sense. Now, it *would not* make sense for a control to call, say, biz.save()[1], because that elevates its role too much. The form is the proper one to call save(). But it simply doesn't follow that therefore it makes no sense for a control to get/set its data field value with the bizobj directly. Form mediation should be encouraged in general, but one should always do what is most sensible in the context of their design. There shouldn't be a litmus test that bypassing form mediation is always bad design. [1] But it could make sense for a control, say a "save" button, to call form.save(). Paul _______________________________________________ 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]
