Commands - Revision history

Hannu Niemisto: /* Recording */

2013-10-22T12:28:36Z

Recording

← Older revision		Revision as of 12:28, 22 October 2013
Line 167:		Line 167:
	</pre>		</pre>
	The first parameter is the current context resource. All references are made relative		The first parameter is the current context resource. All references are made relative
	to that resource that commands can later executed in some other context. The method		to that resource so that commands can later executed in some other context. The method
	<code>gshow</code> works much like <code>show</code> in Prelude, but		<code>gshow</code> works much like <code>show</code> in Prelude, but
	is also able to write expressions for finding resources in ontologies and under		is also able to write expressions for finding resources in ontologies and under
	the context resource. It is defined in the module <code>Simantics/GShow</code>.		the context resource. It is defined in the module <code>Simantics/GShow</code>.

Hannu Niemisto: /* Recording */

2013-10-22T12:28:09Z

Recording

← Older revision		Revision as of 12:28, 22 October 2013
Line 162:		Line 162:
	named <code>context</code> is defined.		named <code>context</code> is defined.

	Command parameters are serialized with a ~~type class~~:		Command parameters are serialized with a function:
	<pre>		<pre>
	~~class RepresentableParameter a where~~		gshow :: GShow a => Resource -> a -> <Proc,ReadGraph> String
	~~representParameter~~ :: Resource -> a -> <ReadGraph> String
	</pre>		</pre>
	The first parameter is the current context resource. All references are made relative		The first parameter is the current context resource. All references are made relative
	to that resource that commands can later executed in some other context. The method		to that resource that commands can later executed in some other context. The method
	<code>~~representParameter~~</code> works much like <code>show</code> in Prelude, but		<code>gshow</code> works much like <code>show</code> in Prelude, but
	is also able to write expressions for finding resources in ontologies and under		is also able to write expressions for finding resources in ontologies and under
	the context resource.		the context resource. It is defined in the module <code>Simantics/GShow</code>.

Hannu Niemisto: /* Java API */

2013-10-22T12:26:31Z

Java API

← Older revision		Revision as of 12:26, 22 October 2013
Line 123:		Line 123:
	== Java API ==		== Java API ==

	Java API for executing commands is meant to be used ~~from~~ during execution of		Java API for executing commands is meant to be used during execution of
	UI operations. ~~Commands are executed in contexts (usually models) that~~		UI operations. A command is obtained with the following method:
	~~must be first~~ obtained~~. New command can be created~~ with ~~<code>newCommand</code>~~
	method ~~in the context. Parameter <code>name</code> is a full path of the~~
	~~SCL-function implementing the command.~~
	<pre>		<pre>
	public class ~~CommandContext~~ {		public class Commands {
	public static ~~CommandContext getContext(Resource resource);~~		public static Command get(ReadGraph graph, String name);
	~~public static CommandContext getContext~~(~~RequestProcessor~~ graph, ~~Resource resource);~~
	~~public Command newCommand(~~String name);
	}		}
	</pre>		</pre>
			The parameter 'name' is the full name of the SCL-function (such as <code>Simantics/Diagram/setTransformation</code>).
			The method never fails but returns a dummy Command-object if the command is not found.

	Command interface ~~has methods~~ for ~~adding and removing parameters,~~ checking		Command interface contains a method for checking if the command is applicable with the given parameters. It may be given less than all parameters of the command. The command can be executed synchronously or asynchronously.
	~~that~~ command is ~~eligible for execution and committing~~ the command.		All methods need a context resource (usually a model) that must be first obtained.
	~~Even if checking accepts the parameter, the~~ command ~~may fail in commit~~.
	~~On failure, an exception is thrown~~ (~~currently no special exception is specified~~).
	<pre>		<pre>
	public interface Command {		public interface Command {
	~~Command addParameters~~(Object ... parameters);		boolean check(RequestProcessor processor, Resource model, Object ... parameters) throws DatabaseException;
	~~Command removeParameters(int count);~~		Object execute(RequestProcessor processor, Resource model, Object ... parameters) throws DatabaseException;
	~~boolean check();~~		void asyncExecute(RequestProcessor processor, Resource model, Object[] parameters,
	~~boolean check~~(RequestProcessor ~~graph~~);		Procedure<Object> procedure);
	void ~~commit~~();
	~~void commit(RequestProcessor graph~~);
	}		}
	</pre>		</pre>
	~~(TODO async methods?)~~

	The interface handles roles automatically. When the current user has no		The interface handles roles automatically. When the current user has no
	privileges to execute the command, check method always fails.		privileges to execute the command, check method always fails.

	~~Example (fictional):~~
	~~<pre>~~
	~~public Runnable renameContribution(Resource target) {~~
	~~final Command command = CommandContext.getContext(target)~~
	~~.newCommand("Simantics/FictionalModule/rename", target);~~
	~~if(!command.check())~~
	~~return null; // Cannot rename the target~~
	~~else~~
	~~return new Runnable() {~~
	~~public void run() {~~
	~~new RenameWidget(command).start();~~
	}
	};
	}

	~~public class RenameWidget {~~
	~~Command command;~~
	~~public RenameWidget(Command command) { this.command = command; }~~

	~~public boolean validate(String name) {~~
	~~boolean result = command.addParameters(name).check();~~
	~~command.removeParameters(1);~~
	~~return result;~~
	}

	~~public void finish() {~~
	~~try {~~
	~~command.addParameters(getName()).commit();~~
	~~} catch(Exception e) {~~
	~~show error to user~~
	}
	}
	}
	~~</pre>~~

	== Recording ==		== Recording ==

Tuukka Lehtonen: /* Java API */

2013-09-26T12:14:56Z

Java API

← Older revision		Revision as of 12:14, 26 September 2013
Line 137:		Line 137:

	Command interface has methods for adding and removing parameters, checking		Command interface has methods for adding and removing parameters, checking
	that command is eligible for ~~exectution~~ and committing the command.		that command is eligible for execution and committing the command.
	Even if checking accepts the parameter, the command may fail in commit.		Even if checking accepts the parameter, the command may fail in commit.
	On failure, an exception is thrown (currently no special exception is specified).		On failure, an exception is thrown (currently no special exception is specified).

Tuukka Lehtonen: /* Defining commands */

2013-09-26T12:13:43Z

Defining commands

← Older revision		Revision as of 12:13, 26 September 2013
Line 118:		Line 118:
	</pre>		</pre>
	The command takes a variable and a value in a string form as a parameter.		The command takes a variable and a value in a string form as a parameter.
	The checking function first ~~check,~~ if the variable is writable. The second		The checking function first checks if the variable is writable. The second
	part of the checking tests that the string value is valid.		part of the checking tests that the string value is valid.

Tuukka Lehtonen: /* Defining commands */

2013-09-26T12:12:06Z

Defining commands

← Older revision		Revision as of 12:12, 26 September 2013
Line 94:		Line 94:
	way in order to make checking of partial parameters possible. Basically some suffix of the signature		way in order to make checking of partial parameters possible. Basically some suffix of the signature
	is replaced by <code>Boolean</code> and any right subtype may be enclosed in <code>Maybe</code>.		is replaced by <code>Boolean</code> and any right subtype may be enclosed in <code>Maybe</code>.
	The checking function may have ReadGraph ~~event~~ and if it has the command system ensures that it is		The checking function may have ReadGraph effect and if it has the command system ensures that it is
	executed in the read transaction.		executed in the read transaction.
	So, if the signature of the command is		So, if the signature of the command is

Tuukka Lehtonen: /* Defining commands */

2013-09-26T12:11:31Z

Defining commands

← Older revision		Revision as of 12:11, 26 September 2013
Line 91:		Line 91:
	role function does not have parameters at all.		role function does not have parameters at all.

	The signature of the checking function is related to the signature of the command in more complicated		The signature of the checking function is related to the signature of the command in a more complicated
	way in order to make checking of partial parameters possible. Basically some suffix of the signature		way in order to make checking of partial parameters possible. Basically some suffix of the signature
	is replaced by <code>Boolean</code> and any right subtype may be enclosed in <code>Maybe</code>.		is replaced by <code>Boolean</code> and any right subtype may be enclosed in <code>Maybe</code>.

Tuukka Lehtonen: /* Introduction */

2013-09-26T12:09:04Z

Introduction

← Older revision		Revision as of 12:09, 26 September 2013
Line 60:		Line 60:
	The first approach has some drawbacks. First, it is not possible to know the allowed roles		The first approach has some drawbacks. First, it is not possible to know the allowed roles
	without first giving all parameters to the function. Second, without adding some new syntactic		without first giving all parameters to the function. Second, without adding some new syntactic
	sugar, the <code>Command</code> -type ~~complicated~~ writing of scripts. Either every command		sugar, the <code>Command</code> -type complicates writing of scripts. Either every command
	has to be wrapped like		has to be wrapped like
	<pre>		<pre>
Line 69:		Line 69:

	The second approach makes possible to define arbitrary properties for the commands, so it		The second approach makes possible to define arbitrary properties for the commands, so it
	is extensible. Its drawback is need for a read transaction for obtaining information about		is extensible. Its drawback is the need for a read transaction for obtaining information about
	commands. It makes it also heavier to define new commands. A command contribution might		commands. It makes it also heavier to define new commands. A command contribution might
	involve additions in three places: Java code implementing the operation, SCL code importing		involve additions in three places: Java code implementing the operation, SCL code importing

Tuukka Lehtonen: /* Requirements */

2013-09-26T12:06:29Z

Requirements

← Older revision		Revision as of 12:06, 26 September 2013
Line 42:		Line 42:
	The second challenge is the serialization of the commands for recording		The second challenge is the serialization of the commands for recording
	so that commands would be valid with maximal probability when replaying		so that commands would be valid with maximal probability when replaying
	in ~~possible little different~~ application context.		in an application context with possible minor differences.

	= Design =		= Design =

Hannu Niemisto: /* Recording */

2013-09-26T10:49:10Z

Recording

← Older revision		Revision as of 10:49, 26 September 2013
Line 208:		Line 208:
	<pre>		<pre>
	class RepresentableParameter a where		class RepresentableParameter a where
	representParameter :: Resource -> a -> <ReadGraph> String		representParameter :: Resource -> a -> <ReadGraph> String
	</pre>		</pre>
	The first parameter is the current context resource. All references are made relative		The first parameter is the current context resource. All references are made relative