On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote:
Aah, but in my scenario, the UI's Init event sets a property ONCE based upon the BizObj's function result, and hence, the scenario you give would still mean no changes to the UI. Hence why I feel that that served the interface idea instead of implementation.
Okay, if the UI is simply caching the response from the BO, then storing it as a property on the form makes sense. However, I still think the BO ought to be a method call rather than a property in an attempt to balance gold-plating the requirements versus getting it done. A BO property like lSuperUser has a binary value (well, trinary: True, False and NULL) but the world is often filled with more complex rules than On or Off. A method call that can initially be coded as RETURN THIS.lSuperUser but later including other functionality gives you a hook on which to hang other functionality without any need to change the interface between the objects. While it's true you can use an lSuperUser_Access method to extend this, why hide the possibility that code fires when you can code a method in the first place? Good discussion, thanks for asking. -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
