Kexi/Plugins/Macros: Difference between revisions

From KDE Community Wiki
< Kexi‎ | Plugins
No edit summary
Line 21: Line 21:
*[https://web.archive.org/web/20041215111332/http://www.saicomsystems.com/AccessPearls/mac-01.asp Example Tutorial of using Macro in MSA]
*[https://web.archive.org/web/20041215111332/http://www.saicomsystems.com/AccessPearls/mac-01.asp Example Tutorial of using Macro in MSA]
*[https://web.archive.org/web/20150529085525/http://blogs.msdn.com/b/thirdoffive/archive/2006/04/18/561495.aspx Embedded MSA Macros]
*[https://web.archive.org/web/20150529085525/http://blogs.msdn.com/b/thirdoffive/archive/2006/04/18/561495.aspx Embedded MSA Macros]
==Introduction==
Macros are abstract actions providing a flexible way to perform dynamic execution-chains. Think of a Macro as simple container to put extended KAction's together.
Those extended KAction's should implement functionality such as:
*call a Qt QObject's slot.
*connect Qt signals and slots together.
*optional use KDE DCOP-functionality for IPC/RPC. We can't depend on DCOP cause it would require to have the DCOP-Server running on each supported platform and may introduce some security related problems.
*optional use the Kross Scripting framework to call a scripting function.
*pass arguments/parameters like a QString around. So, as example if we have the execution-chain myaction1=&gt;myaction2 the value myaction1 returns could be passed as argument to myaction2.
While a Macro does implement functionality such as:
*collect a tree of extended KAction's or even other Macros and execute them if the Macro itself got executed.
*provide an execution context to define local variables once a Macro got executed. That way we are able to share those variables in all extended KAction's the Macro defines.
*marshal/unmarshal the Macro to/from XML to be able to save and restore the serialized XML into Macro instances.
==Use cases==
===Automating tasks===
Automating tasks is one of the main goals that could be archived with Macros.
As example it should be quit easy to execute a Macro each time a project got opened and let those Macro open a form named e.g. "startup" if there exists such a form (so, we are able to define startup-dialogs very easy :-). Another example would be that each time a modified project got saved a script-extensions, provided by the scripting bridge Kross, is executed. That way the user is able to start complex tasks with just one single Macro dynamically connected with some Qt signal.
===Batch-processing===
You may like to automate some work. Let's assume as example we have the actions:
# open a project
# add a new table
# save and close the project
and we may like to execute them with a single click. While it's not possible yet it will be with Macros. Just put all those actions into a Macro and execute the Macro.
Those kind of batch processing needs to implement functionality such as:
* abort execution and throw an exception if one action in the chain failed.
* pass additional arguments/parameters to an action like for the example above; 1) the name of the project that should be opened and 2) the name of the table to add.
* asynchron execution via signal and slots.
* provide an execution context like e.g. access to the KexiMainWindow or to local variables.

Revision as of 22:18, 17 May 2023

{{Macros (the MSA style) are not implemented in KEXI. We're not even sure that Macros Kexi but we know what we want. See external discussions like [1]}}

For a quick introduction to macros see this article for MS Access.

Below is a dump from the old wiki's Macros page.

Generic Macro framework for KEXI
planning started: may 2005, js
planning extended: since jule 2005, sebsauer
development started: october 2005

Definition

Do not confuse Macros with scripts. Macros are simple tasks/actions/commands set up into sequences for later execution. So, they are kind of abstract containers for more specific functionality and useful for automating different tasks.

Macro is a program being dependent on "host" application; Macro has no assigned its own process identifier and private memory area. Script can have all of that. Please read the definition of macros as well.

See also:

Introduction

Macros are abstract actions providing a flexible way to perform dynamic execution-chains. Think of a Macro as simple container to put extended KAction's together.

Those extended KAction's should implement functionality such as:

  • call a Qt QObject's slot.
  • connect Qt signals and slots together.
  • optional use KDE DCOP-functionality for IPC/RPC. We can't depend on DCOP cause it would require to have the DCOP-Server running on each supported platform and may introduce some security related problems.
  • optional use the Kross Scripting framework to call a scripting function.
  • pass arguments/parameters like a QString around. So, as example if we have the execution-chain myaction1=>myaction2 the value myaction1 returns could be passed as argument to myaction2.

While a Macro does implement functionality such as:

  • collect a tree of extended KAction's or even other Macros and execute them if the Macro itself got executed.
  • provide an execution context to define local variables once a Macro got executed. That way we are able to share those variables in all extended KAction's the Macro defines.
  • marshal/unmarshal the Macro to/from XML to be able to save and restore the serialized XML into Macro instances.

Use cases

Automating tasks

Automating tasks is one of the main goals that could be archived with Macros. As example it should be quit easy to execute a Macro each time a project got opened and let those Macro open a form named e.g. "startup" if there exists such a form (so, we are able to define startup-dialogs very easy :-). Another example would be that each time a modified project got saved a script-extensions, provided by the scripting bridge Kross, is executed. That way the user is able to start complex tasks with just one single Macro dynamically connected with some Qt signal.

Batch-processing

You may like to automate some work. Let's assume as example we have the actions:

  1. open a project
  2. add a new table
  3. save and close the project

and we may like to execute them with a single click. While it's not possible yet it will be with Macros. Just put all those actions into a Macro and execute the Macro.

Those kind of batch processing needs to implement functionality such as:

  • abort execution and throw an exception if one action in the chain failed.
  • pass additional arguments/parameters to an action like for the example above; 1) the name of the project that should be opened and 2) the name of the table to add.
  • asynchron execution via signal and slots.
  • provide an execution context like e.g. access to the KexiMainWindow or to local variables.