提取禁用控件的规则

Question

背景

每周我们会让一些用户呼唤帮助,为什么你不能在表单Y上做X.由于复杂的业务规则,我们经常不得不重新查看代码本身,以了解为什么当时没有特定的操作.有没有经过验证的策略来解决这个问题？

如何从GUI,业务规则和/或安全性中收集导致禁用按钮的所有信息？

用户无法从测量概览表中删除测量值,因为

GUI

商业规则

安全

关于我们已经进行计算以确定是否应该禁用控件这一事实的有效评论.

我们使用家庭酿造ACL来处理安全问题.这些是决定是否应禁用控件的步骤

检索全局ACL(当前来自数据库).如果Write ACE存在测量属性的ACL中的a ,则表示当前用户有权更改测量.
度量业务对象获取此全局ACL的副本.业务对象将其业务规则置于检索到的ACL之上.如果业务规则规定测量不应该是可写的,则会Deny Write ACE向ACL 添加a .
请注意,业务对象只能使安全性更具限制性.如果全球安全要求无法完成,则无法完成.
与业务对象的ACL和GUI的耦合是通过我们称之为GuiMap对象的方式完成的.此对象从业务对象检索ACL的副本,并允许开发人员添加返回布尔值的函数指针,以便Gui rules在业务对象ACL之上添加.

现在要确定是否应该启用一个按钮,GuiMap将结合由业务对象的ACL确定的安全性以及具有用户安全性的extremis来评估传递给它的每个函数.

所以事实上,每一层都建立在前一层之上,以确定最终结果.它不像将有一个计算来确定是否应该启用按钮或其他任何东西.

如果你喜欢的话就是这样:当ACL发出副本时,副本会将自己附加到主服务器上,并在主ACL更新时得到通知.这允许我们

这对我们来说非常有效,除了很难知道为什么某些东西被禁用.

Answer 1

如果我理解正确的话，你有两个不同的问题：

1）每一层的检查只返回一个布尔值来指示启用/禁用，而不返回原因。

您必须更改它，以便每次检查也返回原因；例如，您可以返回一个 tuple (enabled, reason)，其中 access 是您现在拥有的布尔值，并给出其被禁用原因的描述（例如作为字符串）。

根据您所工作的环境，更改所有访问检查的返回类型可能不可行；如果你想避免这种情况，你可以报告“带外”的原因，例如将其存储到全局（或更确切地说是线程局部）变量中，就像errnoUNIX或GetLastErrorWindows中的那样。这不是那么优雅，当然，肯定会被很多人皱眉:-(

或者，您可以更改检查以引发异常（带有描述性消息）而不是返回布尔值。再说一次，这在许多环境中都会被人皱起眉头……

2) 您的业务层将条目添加到对象的访问控制列表中。当您稍后检查访问时，您知道哪个条目拒绝了访问，但您不再知道为什么添加此条目。

为了解决这个问题，您可以reason向 ACE 添加一个字段。业务层添加ACE时，会将reason设置为访问被拒绝原因的描述。然后，访问控制检查从这里读取原因并将其传递到 GUI 层，如上所述。