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.
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?
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.
--
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.
