Class LiveViewServerCapability

java.lang.Object
com.streambase.liveview.client.LiveViewServerCapability
Direct Known Subclasses:
LiveViewServerCapability.AggregateMarkGeneration, LiveViewServerCapability.AlertRules, LiveViewServerCapability.AlertWithClusterGroup, LiveViewServerCapability.AlertWithGUID, LiveViewServerCapability.AlertWithQueryString, LiveViewServerCapability.AlertWithQuiescence, LiveViewServerCapability.BlockingDeleteQuery, LiveViewServerCapability.ClientVersionAware, LiveViewServerCapability.ClosablePublisher, LiveViewServerCapability.DataOnRemoveMessage, LiveViewServerCapability.ExternalLiveViewHosting, LiveViewServerCapability.FullSchemas, LiveViewServerCapability.PluggableTableProviders, LiveViewServerCapability.PublishSupportsByteOrder, LiveViewServerCapability.PublishV2, LiveViewServerCapability.ReferenceTablesDirectly, LiveViewServerCapability.ReliablePublisher, LiveViewServerCapability.SavedWorkspaces, LiveViewServerCapability.SeparatelyTransmittedExtendedKeys, LiveViewServerCapability.WorkspacesWithGUID

public abstract class LiveViewServerCapability extends Object

An abstract class for objects that represent a capability of a LiveView server. Capabilities vary from one server release to another.

Each kind of capability is represented by a nested subclass of this main LiveViewServerCapability abstract class. Instead of using a capability "enum", nested class instances let you ask capability-specific "things"; enums don't. For instance, alert rules support and saved workspace support are treated as capabilities which are available in the 1.4 server. In a later release, one or both capabilities may be changed or enhanced. For instance, say server-side saved-workspace functionality is enhanced post-1.4. At that time, the nested "SavedWorkspaces" class can be changed to include methods that get specific details about "sub-capabilities" of the SavedWorkspaces feature. That's preferable to treating every server enhancement as a whole new capability.

When capabilities are first added, yes, all clients want is an "existence" boolean, so initially, empty subclasses are typically what you want.
See Also:
  • Constructor Details

    • LiveViewServerCapability

      public LiveViewServerCapability()