MDrivenWiki
Log in

Modlr plugin

From MDrivenWiki

A Plugin interface is an easy way to allow for you to add your own extensions.

We have now extended the Plugin with yet another interface to facilitate the adding of custom ocl operations. This way the design time functions like CheckModel, ViewModels and OclEditor can be made to recognize your custom operations.

namespace Modlr.Plugins
{
public interface IModlrPlugin
{
string GetName();
List<IModlrPluginMenuOperation> ProvideOperations();
}
public interface IModlrPluginMenuOperation
{
string GetName();
void CheckEnableOrExecute(IEcoServiceProvider esp, bool execute, IEcoObject maincontext, IEcoObject subcontext,out bool enabled );
}
public enum CallbackEventKind {CodeGen,ForcedCodeGen };
public interface IModlrPluginImportantEventCallbackHandler
{
void ImportantEventAboutToHappen(IEcoServiceProvider esp, CallbackEventKind eventkind, ref bool stop, ref string message);
void ImportantEventHasHappend(IEcoServiceProvider esp, CallbackEventKind eventkind);
}
public interface IModlrPluginModelAccessOclType
{
/// <summary>
/// Possible usage - add custom ocl operations that can then be correctly executed by WECPOF and correctly evaluated in OCL design time
/// </summary>
void RuntimeModelAccess(IOclTypeService ocl);
}
}

I added an example in the demos folder called ModlrPluginCodeGenEventsAndCustomOCLOperations

Not going to repeat everything here but a few goodies.

namespace ModlrPluginCodeGenEventsAndCustomOCLOperations
{
public class Plugindemo : IModlrPlugin, IModlrPluginMenuOperation, IModlrPluginModelAccessOclType, IModlrPluginImportantEventCallbackHandler
{
public string GetName()
{
return "AnotherPlugin";
}

The IModlrPluginImportantEventCallback can do things on codegen>

public void ImportantEventAboutToHappen(Eco.ObjectRepresentation.IEcoServiceProvider esp, CallbackEventKind eventkind, ref bool stop, ref string message)
{
// Here you can perform checks before codegen, and optionally stop the codegen
System.Windows.Forms.MessageBox.Show("You are updating the code, this annoying message came from plugin ModlrPluginCodeGenEventsAndCustomOCLOperations");
}

But the brand new interface is the IModlrPluginModelAccessOclType>

public void RuntimeModelAccess(IOclTypeService ocl)
{
ocl.InstallOperation(new CustomOCL_SplitAtSemi());
}

And the operation (really a different subject) looks like this:

public class CustomOCL_SplitAtSemi : OclOperationBase
{
public CustomOCL_SplitAtSemi()
{
}
protected override void Init()
{
InternalInit("SplitAtSemi", new IOclType[] { Support.StringType }, Support.StringType);
}
public override void Evaluate(IOclOperationParameters __Params)
{
string s = Support.GetAsString(__Params.Values[0]);
string[] ss=s.Split(';');
string first = "";
if (ss.Length > 0)
first = ss[0];
Support.MakeNewString(__Params.Result, first);
}
}

So this is really super because my model validates in design time even if I use the custom operation:

Modlr plugin - 1.png

Viewmodel columns that use the custom expression are evaluated correctly:

Modlr plugin - 2.png

CheckModel stays empty since everything is validated:

Modlr plugin - 3.png

And of course the prototyping actually executes your operations:

Modlr plugin - 4.png

Modlr plugins

We added a plugin interface for Gaffr and ECO. We want to enable you to extend Modlr so that you can implement a special file format import, or export, or what have you.

This is how it works:

Given these two interfaces…

namespace Modlr.Plugins
{
Public Interface IModlrPlugin
{
string GetName();
List<IModlrPluginMenuOperation> ProvideOperations();
}
Public Interface IModlrPluginMenuOperation
{
string GetName();
void CheckEnableOrExecute(IEcoServiceProvider esp, bool execute,
}
}

…you can implement a plugin in an assembly like this:

public class Class1 : IModlrPlugin
{
#region IModlrPlugin Members
public string GetName()
{
return "Demo plugin";
}
public List<IModlrPluginMenuOperation> ProvideOperations()
{
List<IModlrPluginMenuOperation> ops = new List<IModlrPluginMenuOperation>();
ops.Add(new OperationShowDialog());
ops.Add(new OperationActOnClass());
return ops;
}
#endregion
}

The code above installs two Operations; OperationShowDialog and OperationActOnClass.

Looking closer on the operation ActOnClass:

public class OperationActOnClass : IModlrPluginMenuOperation
{
#region IModlrPluginMenuAction Members
public void CheckEnableOrExecute(IEcoServiceProvider esp,
{
enabled = false;
if (maincontext != null && maincontext.AsIObject().AsObject is Eco.ModelLayer.Class)
{
enabled = true;
if (execute)
{
(maincontext.AsIObject().AsObject as Eco.ModelLayer.Class).Name += "X";
}
}
}
public string GetName()
{
return "Operation on class";
}
#endregion
}

The code checks that the context is a class, and if it is the code says that the operation should be enabled. If this was an “execute” call we perform the desired logic – in this case I just add an “X” to the back of the class name.

You can do a lot of stuff in a plugin. You get access to the IEcoServerProvider for the EcoModelLayer. The Modlr application is a standard ECO-built-application so you can use the IOCLService to get to any object, of any class that builds up your model content. You can access Diagrams, PlacedClasses, StateMachines etc. You can inspect and set TaggedValues, you can run thru every Attribute and check for spelling errors. You can create reports that you share with other ECO/Gaffr users…

So even if the interface is very small and simple, it is very powerful.

When you build your Plugin you will want to reference the following assemblies (found in the eco or gaffr install directory):

Modlr plugin - 5.png

Compile your plugin and put the assembly in the folder %ProgramData%/CapableObjects/Plugins

Restart Gaffr.net or VisualStudio and you will find your plugin operations in the context menu:

Modlr plugin - 6.png

Simple and powerful.