Ted Roche wrote:
On 8/9/06, MB Software Solutions <[EMAIL PROTECTED]> wrote:I had originally thought of something simple like "this.enabled = thisform.oBizObj.IsSuperUser(tcUserID)" but I didn't like the idea of a function being called across object lines several times (repetitively, as Refresh events would have happen).You could be guilty of premature optimization here, but it's a judgement call. Object-to-object calls within VFP objects are nowhere near as heavy as object calls between COM objects. At the other extreme, it could be argued all object-to-object communication could be Get() and Set() functions, which _Access and _Assign provide, although in a manner that feels kludgy to me.
Gotcha.
Rather than let the BO handle the abstract question - "Should this
control be enabled?" - you define the Business Rule ("This control
should be enabled if the user is a SuperUser") in the call the UI
makes. UIs shouldn't know or care about Business Rules. If next
month's iteration is that that control should be enabled for
SuperUsers or PowerUsers but not for Bob, it would make more sense to
change this Business Rule in the Business Object than in all the
places the UI code that calls it, wouldn't it?
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.
True, but what I didn't say in my simplistic example is that there were a few other factors, such as "enable if this guy is a SuperUser and these other data criteria are met (like name filled in, date is valid, etc. etc.) so hence why I put it in the refresh event. In the case where it's merely a matter of user role and NOT dependent on other data being validated at time of execution, then yes, I agree----Init only. (I think I mentioned that exact point earlier--that his role wouldn't change during the lifetime of the form's run.)And why the Refresh() event? Is a user's status that likely to change during the lifetime of a form, or is it better to require a change in security levels to necessitate the user log out and back in? That way you check once on Init() and never again, cutting down on the number of calls.
Thanks for your insights/comments, Ted! -- Michael J. Babcock, MCP MB Software Solutions, LLC http://mbsoftwaresolutions.com http://fabmate.com "Work smarter, not harder, with MBSS custom software solutions!" _______________________________________________ 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.
