WinPTE.com

 

Data store Concept

What is a Data Store?

Data store is a concept I dreamt up to make configuration and script exposure of different elements of WinPTE easier. At its heart it is a hierarchical database with event driven interface. Every element can have a single arbitrary value and an ordered list of uniquely named child elements. These in turn can have the same.

The data store implements a transactional model so that all changes can be grouped into transactions and committed/rolled back as a single unit. Additionally all elements generate events when operations are performed on them. This allows external observers to be informed when an element value is changed or one of its child elements is modified, added or removed.

Element name can contain any character except NUL or / the latter is used as path separator.

The persistence of the data has been implemented as a simplified XML parser/generator. It is fast and simple. At the moment the data store element values are always stored as ANSI, UNICODE strings or hex encoded binary CDATA elements.

Each element in the data store can be serialized with the rest of the data (WinPTE.xml in application data/winpte directory is the whole kit and caboodle) or each element can override the serialization location for itself and its child elements. Workspaces are implemented as elements that override the storage location. Additionally elements can be non-serializable as is done for options.xml (Options pane configuration) which is stored in the installation directory and is read-only from WinPTE. Or can be stored in the standard location and a separate file (parallel saving). This is used for the color schemes because WinPTE needs to have the color configuration loaded early in its start-up process.

There are other functions such as aliasing. Which allows mapping of any node (and its child elements) to another node. This is used for Workspace implementation. The default workspace is stored in /editor/session/settings/workspace, when another workspace is selected a node /editor/session/settings/currentworkspace is loaded from the selected workspace file and /editor/session/workspace is aliased to /editor/session/settings/currentworkspace/workspace, additionally recent/files, recent/directories and /editor/session/window are also aliased to child nodes of the currentworkspace node. This functionality decouples dependencies since all other access continues to use the original path for the data and is automatically remapped to the new location.

The configuration of the display engine and the options pane make heavy use of the event driven functionality of the data store. The display engine changes configuration when the data store elements of concern get modified. The options pane also changes the displayed property when the data store element changes. Additionally the options pane modifies the data store element only, relying on the event mechanism to inform all affected parties that they need to change their configuration.

Custom events can be defined and fired on any element in the data store. This functionality is used by the options pane to resolve the Styles since a transparent background does not mean the same thing for Text (which can use Text or Margin Styles) or the Status Bar which uses the default Button Face color and Button Text colors. So the Options pane fires a custom event on a style node requesting that the Style be resolved to absolute values for painting. Similarly the Options pane is clueless as to what font should be used to paint the style text. It simply fires another custom event on the style element requesting the font information. The TextView or the Status Bar respond to these events for the style elements they are involved with and provide the information to answer the request, in this case that of the Options Pane.

The decoupling eliminates the need for any of these components to know of each others existence. They simply interact with the data in the data store and leave the plumbing to it. This decoupling plays a big role in script exposure. Simply put, once the data store interface is exposed to a script engine, the script gains access to all elements of WinPTE exposed in the data store without having to expose each single element or write another line of code.

Another benefit of the data store. is persistence. Once a value has been wired to the data store restoring its state on start-up is automatic since the data store is saved on application exit and loaded on application start up.

Element paths are arbitrary from the data store point of view and I simply chose to organize them under /editor element for all WinPTE settings,

Here are some paths the WinPTE is using. The best current reference is WinPTE.xml found under Documents and Settings/UserName/Application Data/WinPTE/WinPTE.xml or you can open the PTE project in the projects pane and double click on WinPTE.xml and it will load the file used for the current WinPTE session.

Full Path Child Element Value/Action
/editor/session/window

 

show

0 - show restored, <0 - minimize, >0 maximize. Changing the value changes the main display window and vice versa.

left, right, top, bottom

The window coordinates for the main window. Changing these moves the window and vice versa

/editor/config/options see options.xml in the installation directory Contains the groups, categories and properties displayed in the options pane
/editor/session/dialogs findreplace All the settings for the find replace dialog. These are live so changing the data store value will update the dialog content/state or move the window
/editor/session/panes colorchart stores the color chart settings and current display state.
todo stores the selected tags and whether all files or tags from just the current file are displayed. This is store/retrieve only. Changing the data will not be reflected in the todo pane. (Future addition)
options The current state of the options pane. Changing the values will affect the current display of the options pane and vice versa
/editor/session/textview many (see WinPTE.xml or any of the color scheme files in the installation dir (*.clr)) Stores the styles and display options for the text display engine. Changing values changes the current display settings. The options pane changes the data store value to affect a display change.
/editor/session/statusbar many, see WinPTE.xml settings for the status bar styles and font
/editor/session/qnaglobal child nodes are Question ID, sub-nodes contain default answer and dialog size and position. All dialogs in WinPTE can have a "Use As Default Answer" option enabled. If this is done then the answer (Yes, No, Cancel) will be provided automatically and the dialog will not display again. These answers are stored in the data store. Also each dialog uses a QuestionID (arbitrary character string) which is used to uniquely identify each user query and associate a canned response, store the size and position of the dialog box.

There is a primitive command line interface to the data store, which I will document at a later date or sooner if someone is interested.

To maximize the main window execute (type the text and hit ENTER in the WinPTE command line, ESCAPE toggles between text and command line) the following:

datastore set /editor/session/window/show 1

To restore the window size execute:

datastore set /editor/session/window/show 0 

To minimize:

datastore set /editor/session/window/show -1

 

 

Site Map | Privacy Policy | Contact Us | ©2004 Winpte.com