Kexi/Plugins/Macros

{{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 such as [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:

• Discussions
• Automating Tasks in Microsoft Access
• Description of what is Macro in MSA
• Example Tutorial of using Macro in MSA
• 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=>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.

Actions in Kexi Forms

Kexi does include an own data-aware WYSIWYG Form Designer to let users build nice forms with just some clicks. At the moment it's possible to connect a button with "Assign Action" with most Kexi actions to execute the defined shared action if the button has been clicked. For example it's possible to call a Kross Scripting function or to just call a slot the KexiMainWindow provides or to connect the button's "click" signal with a Macro (if the user clicks the button the Macro is executed).

More info: Form Actions

Macro and scripting

Kexi provides the Kross scripting bridge to enable using of embedded interpreters like python. That way users are able to write complex python scripts to e.g. access the whole KexiDB functionality. At the moment scripting is used to provide scripting extensions like the "ExportHTML.py" to export a table or a query to a HTML-file or the "ProjectDocumentator.py" that generates some kind of project documentation including details about the tableschemas the project uses. Both scripts are local installed part of the Kexi-application. Scripting code embedded in a project is the other usage-scenario. There the scripts are bind to a single project and not stored local rather then in the project-database. In that case the Scripting editor is used to allow the user to edit those scripts. We arn't able to access e.g. forms from within scripting or activate actions Kexi provides or just call slots the Querydesigner provides. To archive that we would need Kross-wrappers for all those functionality Kexi provides. Also it would blow up the clean API we have right now between Kexi and Kross (the code in kexi/core/scripting.{h|cpp} does handle the whole connection between both code-bases and beside those code there is no dependency between Kexi and the Kross-framework).

Macros don't need to take care of dependencies cause they are designed to depend on the application that uses the Macro-framework. They are much more abstract and limited to fit only a hand full of tasks like automating or batch-processing. They provide a GUI for comfortable editing rather then an own whole interpreter-language you have to learn to deal with.

The Macro-framework provides a bridge between Kexi-functionality and the Kross scripting bridge. Kross would only need to wrap the Macro-framework and earns access to the Kexi-application that way without depending on the application itself and without knowing something about those host-application. So, the Macro-framework would be a bridge between Kexi and Kross and each application that uses the Macro-framework would be transparently accessible by the Kross too (Kross <=> Macro <=> Application). In the end it's all about beeing flexible and having clean and maintable interfaces between those components.