The catalog of subject slots a rule can read from.
A subject is a piece of context, the current user, the object on
screen, an action being filtered. Each key here is a slot name; the
value type is what RuleScope.get(slot) returns for it.
This package declares three first-party slots (user, limeobject,
action) so that any registry implementation has a common baseline
to register. The slot types are defined here; the implementation
still has to call
registerSubject for each at
bootstrap.
Plugins add their own slots by extending this interface:
Use namespaced keys (mypkg.foo, pluginx.bar) for plugin-added
slots. Two plugins declaring the same key with different value types
will collide at compile time. The built-in slots user,
limeobject, and action are first-party and intentionally use
short, unnamespaced ids. The namespacing convention only applies to
non-built-in slots.
The catalog of subject slots a rule can read from.
A subject is a piece of context, the current user, the object on screen, an action being filtered. Each key here is a slot name; the value type is what RuleScope.get(slot) returns for it.
This package declares three first-party slots (
user,limeobject,action) so that any registry implementation has a common baseline to register. The slot types are defined here; the implementation still has to call registerSubject for each at bootstrap.Plugins add their own slots by extending this interface:
Example
Use namespaced keys (
mypkg.foo,pluginx.bar) for plugin-added slots. Two plugins declaring the same key with different value types will collide at compile time. The built-in slotsuser,limeobject, andactionare first-party and intentionally use short, unnamespaced ids. The namespacing convention only applies to non-built-in slots.See