layout |
---|
default |
{% include links %}
- TOC {:toc}
SeLite Settings (Components > Settings) allows easy custom configurations of Selenese scripts and [Core extensions][core extension].
Selenium IDE can be extensively customised via [Core extensions][core extension] (written in Javascript). This way you add new Selenese [commands][command] and related functionality. Many extensions are worth reusing (by yourself, within your team or publicly). But then they often need to be configured, e.g. in regard of
- users or credentials
- location of XML files (which an extension can pass to loadXmlVars and forXml from [SelBlocks Global])
- location of SQLite data files
There was no convenient tool to
- edit
- validate
- share and manage such configurations.
Most [Core extensions][core extension] can work with
- just a few basic field types
- an option for custom validation of fields
- simple user interface
- no need for sophistication, since it won't be used frequently (as compared to other GUI parts of Selenium IDE)
- done once for benefit of many
- easier to use, share and manage than
- editing Javascript files (possible typos..), or
- using Firefox's special URL about:config, which would
- hard-code preference names
- allow only one configuration per Firefox profile. That is counter productive if you need to switch between configurations, since the profile contains the installed extensions, history etc. Copying the profile folders can lead to a mess.
- an API to access the configured values
You could create custom GUI as an IDE [extension of Selenium IDE] through XUL overlays (in XML). But
- you shouldn't need to learn all that, especially because XUL is
- different to HTML, and not of much use (unless you create visual extensions of Firefox)
- difficult to debug
- not well documented (some features)
- from [script] developer's perspective, making extension(s) configurable is a not as productive/motivating as creating extensions themselves
It defines API and GUI that simplify management and sharing of configurations. They
- organise fields in modules and sets
- use Firefox preferences and/or manifest files
- allow fine-grain granularity
- enable adding custom fields to existing configurations
- populate default values
- validate free-type values
- give end users (e.g. testers) visual interface, which is nicer than Firefox URL about:config
- present settings as they apply to a chosen folder
You can
- define configuration schemas (called modules) and their fields
- store any number of configuration sets (or their parts) per module in
- plain text files ({{valuesManifest}}s), and/or
- Firefox profile and
- edit them through a generic interface in a browser
- choose one that is default (if the module allows multiple sets)
- associate them to folders containing [suites][suite] (if the module allows to be associated with folders)
- alternatively edit them access via url about:config
- have your [Core extension] access the preferences via a Javascript code module (API)
Associated sets and {{valuesManifest}}s work only in standalone Selenium IDE, but not in SeleniumIDEtips > auxiliary Selenium IDEs inside browser (neither in Selenium IDE in browser sidebar).
Modules are schemas/templates of user's configuration(s). They define each field:
- its name
- its type
- whether single-valued or multi-valued
- default value(s)
- custom validation (optional)
Test developers define configuration modules (schemas) in Javascript. See SettingsFields and SettingsAPI.
User's configuration(s) - values of the fields - are grouped in set(s). Those are stored in Firefox preferences. A module can have either
- exactly one set, or
- any number of sets; one of them can be selected as default
Settings also works without Selenium IDE and without manifests. So it may serve any Firefox extension.
Users can configure and override settings granularly via
- profile-based configuration sets
- through user interface
- not shared with other team members
- applied to [suites][suite] through {{associationsManifest}} file(s)
- manifest file(s)
- in plain text
- in folder(s) on the [suite] file path
- exist in two types
- {{valuesManifest}}s
- {{associationsManifest}}s
- can be shared, distributed and updated within a team via
- a shared drive, or
- source versioning system
For an example see SettingsInterface. If accessing configuration from [Core extensions][core extension], see SettingsAPI.