From MightyWiki

Jump to: navigation, search

Action Providers are core elements that have the ability to provide collection of Actions (similarly to Item Sources and Items) for the engine. As apposed to Item Sources that are indexed every x period of time, actions are loaded only once, when Mighty Box starts.

Besides providing action, Action Providers are also accountable for setting the policy of how to use those actions. APs define the valid subjects types for each action as well as valid parameters (if any). Mighty Box engine only allow to run actions on compatible subjects, therefore unsupported actions will never appear in the Action Selector when selecting a subject. There are two ways for an AP to define valid subjects:

Using the ValidSubjectTypes property, an AP can limit the range of subject to those of specific types (for example, only file subjects).
By overriding the validActionsForSubject(MBItem subject) function, an AP can implement a more strict set of rules (for example, diffrentitate between executable files, or remote files, etc.) and also map different action lists to different subjects. This function will only receive subjects of valid subject types as defined above, so the programmer does not have to check type safety each time.

Architecture

There was a question of architecture, when deciding how should abstract actions be implemented.

Inheritence

The first option which came to mind was having each custom action inherit from MBAction, and implement some sort of interface. This would cause piles of half empty classes, and duplicated code, and also it may be difficult for each action class to access shared resource among plugins, like a a COM object, or open http connection for e.g. It was decided that this is just bad programming, and not a good solution.

Action Providers

The second idea was creating a type, later named Item Provider, that will define actions using simple MBAction instances along with action delegates. This design allows the programmer to initiate a list of actions easily inside an AP, and possibly set the actions delegates point to member functions of the AP (Example implementation below). Not only this method of programming is simpler to code and maintain overtime, all the actions can now use the same resources since all the action functions are defined within a single class. It is recommended to create an AP for each subject type, or for each plugin.

Code Sample

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using MightyBox.Core;
using System.Diagnostics;
using MightyBox.Core.Plugins.FileSystem;
using System.IO;
 
namespace MightyBox.Core.Elements
{
    class FileSystemActions : MBActionProvider
    {
 
        // action identifiers
        public const String kOpenAction = "FSOpenAction";
        public const String kOpenWithAction = "FSOpenWithAction";
        public const String kOpenFileAction = "kOpenFileAction";
 
 
        public FileSystemActions()
        {
            // Set this action provider to support only subjects of type File
            ValidSubjectTypes = new Type[] { typeof(FileItem) };
 
            Actions = new List<MBAction>();
 
            // Init actions
            MBAction openAction = new MBAction()
            {
                Identifier = kOpenAction,
                Title = "Open",
                Description = "Open the selected file",
                Action = doOpenAction
            };
 
            MBAction openWithAction = new MBAction()
            {
                Identifier = kOpenWithAction,
                Title = "Open With...",
                Description = "Open the subject file with selected app",
                Action = doOpenWithAction
            };
 
            MBAction openFileAction = new MBAction()
            {
                Identifier = kOpenFileAction,
                Title = "Open File...",
                Description = "Use subject app to open the selected file",
                Action = doOpenWithAction,
                ReveseArgs = true
            };
 
            Actions.Add(openAction);
            Actions.Add(openWithAction);
            Actions.Add(openFileAction);
 
        }
 
        public override List<MBAction> validActionsForSubject(MBItem subject)
        {
            // Here we need to filter which actions are allowed for subject, 
            // applications, media files, document, support different actions
 
            return Actions; // tmp
        }
 
        public override List<MBItem> validParamsForAction(MBAction action)
        {
            throw new NotImplementedException();
        }
 
        // actions:
 
        private MBItem doOpenAction(MBItem subject, MBItem param)
        {
            return doOpenWithAction(subject, param); ;
        }
 
        private MBItem doOpenWithAction(MBItem subject, MBItem param)
        {
            String filePath = (subject as FileItem).Path;
            Process process = new Process();
 
            if (param == null) // open with default app
                process.StartInfo = new ProcessStartInfo(filePath);
            else
                process.StartInfo = new ProcessStartInfo((param as FileItem).Path, filePath);
 
            //process.StartInfo.WorkingDirectory = Path.GetDirectoryName(filePath);
            process.StartInfo.UseShellExecute = false;
 
            try
            {
                process.Start();
            }
            catch (Exception ex)
            {
                //TODO: Log
            }
 
            return null;
        }
 
    }
}

Action Provider

From MightyWiki

Contents

Architecture

Inheritence

Action Providers

Code Sample

Views

Personal tools

Navigation

Search

Toolbox