Rapid Database Application Development
|
||
Development |
"Microsoft Access for Linux"
|
|
Macrosworking title: KoMacro / KexiMacro target: Generic Macro-framework for Kexi (proposal for KOffice) planning started: may 2005, js planning extended: since jule 2005, sebsauer development started: october 2005 DefinitionDo 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
IntroductionMacros 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 like
While a Macro does implement functionality like
Usage^ tocAutomating tasksAutomating 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 dynamicly connected with some Qt signal. ^ tocBatch-processingYou may like to automate some work. Let's assume as example we have the actions
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 like
Actions in Kexi FormsKexi 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). ^ tocMacro and scriptingKexi 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). At the end it's all about beeing flexible and having clean and maintable interfaces between those components. ^ tocDesign^ tocAction
Macro
Function
Context
Variable
SecurityIt is very difficult to provide a strong security around a scripting interpreter like python. For Macros it's damn easy to limit access cause we are able to define the functionality a Macro is able to access. We don't need to take care of different levels of trust cause Macros are always untrusted. They may come from untrusted sources like a remote database if stored within a KexiProject. They are just not able to access the filesystem and wipe off your home-directory! While Macros are only little helper to get stuff automated, we may like to add someday a way to access dcop or to call scripting code like an extension. As you may imagine those topics are security-related and we need to take care of any kind of connection we put between Macros and such code. One way would be to just ask the user if a Macro e.g. tries to call a scriptfunction and warn him. The better cause more flexible solution would be to implement the Security-Manager and use it for Macros that try to access possible insecure areas.
Example solutions
Ideas
Developing^ tocDiagram of componentsAn overview of where KoMacro could be located.
|
|||||
|