App Framework Glossary

A B C D E H I J L M N P Q R S T V

Note: For general Splunk terms and definitions, see > Splexicon

-A-

abstract class

Actually, an abstract base class which may define methods to be implemented by subclasses. Abstract classes enforce inheritance hierarchy.

App Framework uses the mechanism, in Python and JavaScript, for apps to hook into the framework, by sub-classing. The following are abstract classes:

  • Splunk.Module
  • Splunk.Module.DispatchingModule
  • ModuleController
  • ModuleHandler
  • BaseController

See also: base class, extension point

add-on

App implementations that have configurations, knowledge, inputs, outputs, and workflows that classify, transform, or normalize data, and are intended to be used by one or more apps are called add-ons.

An add-on provides a container for knowledge (event types, field extractions, lookups), scripted inputs, and other extensions to core Splunk capabilities, which may or may not be technology-, product-, or solution-specific.

Note : Add-ons should not depend on other apps or add-ons for correct operation.

Add-on packaging facilitates distribution to Splunk instances.

See also: app

App Framework

The App Framework is a set of core Splunk software and architecture principles that provides large-scale reuse in creating Splunk apps and add-ons. App Framework extension points provide hooks into framework module, AJAX, and MVC components and patterns, facilitating custom application development.

See also: AJAX, app, add-on, MVC, module

app

An app is a redistributable package containing some or all of the following components:

  • Configurations
  • Views
  • Modules
  • Controllers
  • Templates
  • Models
  • JavaScript
  • Static Content (HTML, CSS, Images)

In general, apps create a compelling and enriching user experience for exploring data produced by a particular,

  • Technology
  • Product
  • Solution

Apps provide a container for custom workflows, views, and other extensions to SplunkWeb. Apps also contain saved searches, macros, and other knowledge for working with domain-specific data and objects.

App packaging is intended to facilitate distribution to Splunk instances. Apps are commonly distributed using the app and add-on repository on SplunkBase but can also be distributed using Splunk Web or by extracting the package within the Splunk file system.

Apps may or may not depend on one or more add-ons for their correct operation.

See also: add-on

application

The term application refers to domain-specific software, independent of a particular implementation. Applications achieve significant reuse in the Splunk environment by being implemented using the App Framework. Apps and add-ons are application implementations.

See also: add-on, app

-B-

base class

The class from which another class inherits is a base class, providing structural integrity.

Sub-classing a base class is the App Framework mechanism for hooking an app into framework functionality. Applications usually need to implement required base class methods in a way that modifies App Framework behavior to suit application requirements.

See also: abstract class

bind (events)

Web programming typically requires that a method or function is bound to a particular user or program event to perform the desired action when the event occurs. Binding, effectively, attaches a callback function to some event or action.

For example, AJAX request parameters include a completion function to be executed when the request completes.

Also, see the jQuery bind() method for binding browser events to DOM elements.

You can override default Splunk event handlers by implementing a custom handler in the application.js file. A number of API methods, such as dispatchJob(), also permit you to specify callback functions on success or failure of the operation.

See also: event, event handler

-C-

CherryPy

CherryPy is a Python framework for building web applications. App Framework uses CherryPy to handle HTTP requests, including session handling.

context

Definition coming soon ...

controller

Definition coming soon ...

-D-

decorator

Definition coming soon ...

-E-

entity

The MVC model consists of entities (configuration objects or similar artifacts), which are REST resources accessed using the REST API. Entities are uniquely identified by ID and have associated metadata attributes, or model fields. The SplunkRESTManager class usually represents a unique entity and provides a number of API methods to abstract the REST interface for manipulating entities. Entities can also be created and deleted. (See Model API)

event

DOM Events Definition coming soon ...

Splunk Events Definition coming soon ...

See also: bind, event handler

event handler

Definition coming soon ...

See also: bind, event

eventtype

Definition coming soon ...

extension point

Definition coming soon ...

-F-

field

(See model field)

-H-

hidden module

Definition coming soon ...

-I-

ID

MVC model entities are uniquely referenced by ID, which is a string representing the hierarchical REST API path to a configuration object or similar artifact. (See Model API)

Example: /servicesNS/admin/search/saved/searches

-J-

job

Definition coming soon ...

job progress

Definition coming soon ...

-L-

log

Definition coming soon ...

loosely-coupled add-on

Definition coming soon ...

-M-

Mako templates

Definition coming soon ...

metadata

Metadata are the ownership, access control, sharing, and mutability settings associated with an entity. The ObjectMetadataModel and SplunkAppObjModel classes abstract operations on resource metadata contained in model fields. (See Model API)

mode-less workflow

Definition coming soon ...

model

Definition coming soon ...

model field

A model field is an attribute associated with a given entity, as defined by the model class . Fields have the notion of mutability. (See Model API)

module

Definition coming soon ...

module configuration

Definition coming soon ...

module controller

Definition coming soon ...

-N-

namespace

Definition coming soon ...

-P-

parent

Definition coming soon ...

parent container

Definition coming soon ...

-Q-

query set

Definition coming soon ...

-R-

resource

A partial resource path used to build Entity Id's (e.g. "resource = 'saved/my_object'"). (See Model API)

result

Definition coming soon ...

-S-

search

Definition coming soon ...

search pipeline

Definition coming soon ...

self

Self is a Python keyword used in class instantiation that refers to the instantiated object, itself. By convention, the keyword cls may be used interchangeably with self.

-T-

template

(See Mako templates)

-V-

view

Definition coming soon ...

view configuration

Definition coming soon ...

View XML

Definition coming soon ...