2

然后是在我们的 Web 应用程序中实现某种成就的时刻。我有一个或多或少类似于这个问题如何在 RoR 中实现成就系统中描述的层次结构的想法。

我们正在开发的应用程序是一种软件即服务，旨在在没有软件开发人员的情况下进行外部管理。问题是软件管理员应该可以通过 Web 界面创建新的成就运行时。然后层次结构变成一堵墙。

我在某处读过可以通过有限状态机来实现这种情况，但目前我没有足够的关于该主题的信息。

编辑：具体问题

我考虑过用一系列要满足的条件来建模一个成就类。这个基本类的成就将有一个布尔值，它递归地检查所有条件是否有效。然后条件可以是硬编码的类。然后系统管理员通过原子条件的组合创建新的成就。

我担心的是越来越多的原子条件类。我不想在项目中有 30 多个条件类。任何建议都非常感谢。

编辑：有关实施的更多详细信息

从 SpyrosP 的响应来看，构建所描述的 DSL 似乎是个好主意。然后必须以某种方式将成就保存在数据库中。保持相同的例子：

comments :less_than => 10
check_comments
comments :more_or_equal => 100
award_hundred_comments_badge

为了动态地创建成就，应该有一个表来存储要检查的条件：

Achievement
| id | name                |
| 1  | "Houndred Comments" |

Condition
| achievement_id | expression             |  
| 1              | some sort of condition |
4

1 回答 1

1

我一直对同一个想法感兴趣，并且前段时间正在阅读不同的东西。可能最好的方法是使用观察者。观察者就像一个标准过滤器（before_filter 等），但有一些区别，比如如何处理返回值等等。

也就是说，如果你的系统真的很复杂，你可能想要使用像https://github.com/pluginaweek/state_machine这样的状态机插件。但是，我觉得这对于成就功能来说太过分了。

如果我不得不面对复杂的成就场景，我可能会创建一个简单的 DSL 来定义成就的行为。就像是 ：

for_achievement :hundred_comments do
  before_achievement :status => Comment, :lower_than => 100
  after_achievement :status => Comment, :more_or_equals => 100
end

你明白了。这将是一种全面描述成就的方式。然后，您的观察者将能够使用您的成就.rb 类场景，以确定是否达到了成就。想想 CanCan 的工作方式。这也可能是您的管理员通过比我在上面的示例中展示的更简单的 DSL 编写简单的成就要求的好方法。

希望能有所帮助，或者至少给你一些想法:)

编辑：更简单的 DSL

DSL 可以非常简单且富有表现力，因此人们甚至可能喜欢用它来编写场景。就像是 ：

comments :less_than => 10
check_comments
comments :more_or_equal => 100
award_hundred_comments_badge

这很容易形成达到 100 条评论的有效场景。让我们设想一个场景，如果用户邀请了 10 个性别女性，他将获得一个徽章。

invites :less_than => 10, gender :female
check_invites
invites :equals => 10, gender :female
award_women_invitations_badge

现在，如果您向他们解释有关 DSL 的基本知识，我认为即使对于不了解 ruby​​ 的管理员来说，这也很容易编写。但是，如果您不希望他们参与其中，您可以创建如下表格：

Action Dropdown => [Comment, Invite, Post, ....]
Condition => [Equal, Less Than, More Than, ....]
Condition_Value => (TextBox to write value to)
CheckCondition => [Check Invitation Count, Check Messages Count, ....]
于 2012-02-27T17:03:29.580 回答