Rapid Database Application Development
"Microsoft Access for Linux"
|
|
|
Rapid Database Application Development
|
| Development |
"Microsoft Access for Linux"
|
|
|
Macros: Discussionstarted by jstaniek, 2006-03-29 extended by sebsauer, 2006-05-14 This is temporary page usable for random discussions needed for Macros framework development. TODOs
^ toc GUI, Part I
GUI as frontend to the user to view and edit macros. We need an abstraction-layer between the Macro-GUI functionality and the application that likes to use the GUI. As Example Kexi could reuse the KoPropertyView and the KexiTable to manage Macros while another application doesn't use KoPropertyView at all. "The goal is that the user has to be able to understand what macro does without even looking at the manual." ^ toc GUI, Part II
Kexi provides own UI-elements like the KexiViewBase ^ toc Integration into Kexi, Part I
^ toc Integration into Kexi, Part II
We need a way to connect e.g. a buttons click-event with "Execute Macro". Currently Kexi provides a way to achieve exactly this by using the "Assign Action" Dialog displayed at the contextmenu of a button. There are two ways to achieve the goal of integration;
^ toc User-Handbook
We need to produce a user-handbook how to use macros. ^ toc IssuesMore general issues regarding the Framework. ^ toc Synchronous or asynchronous macros?
jstaniek, 2006-03-29: I'd vote for synchronous for now. There are many actions like "open dialog", "close window" that can work very well as synchronous. Especially for modal dialogs we expect synchronouos execution. There are cases when asynchronous macro can cause crashes when application is not designed to work asynchronously. I learned that such crashes can be hard to fix. When could be asynchronous macro action usable? In Kexi context, e.g. for processing large data. But this action is the one we plan to make asynchr. anyway, independently of macros. Thus the same async. functionality can be accessed in three ways: 1. directly by user's mouse clicks; 2. within macros; 3. within scripts. For above scenario, having async. data processing action, we may just need an execution context returned back to macro executing engine, so macro users can decide whether (1) they want to wait (block the macro execution) or (2) not. In case (1): macro engine will create a wait condition and sleep doing nothing before the action terminates. In case (2), the macro will continue without knowin anything about successfull termination of the action. Example action sequences in schematic notation:
(1)
run_large_query( update query, WAIT ) /* this takes 2 minutes */
do_something_for_the_updated_data() /* this will be executed after
successfull termination of
the above action */
(2)
run_large_query( update query, DONTWAIT ) /* this takes 2 minutes */
do_something_different() /* this will be probably executed in
parallel to the above action */
sebsauer, 2006-03-31: Steps
sebsauer, 2006-04-01: Partly done now. We are able to decide via Action::setBlocking() if execution is done sychron or asynchron. GUI-related: Do we really like to have an option at the GUI for that functionality? sebsauer, 2006-04-23: I would propose to declare this done cause remaining is GUI-related. ^ toc Does a Macro need to be an Action?
jstaniek, 2006-03-29: Complexity! I believe we need to keep macros functionality available for Joe User. As I understand what we wanted to achieve by "Macro is an Action too." here's what I's propose instead of this:
That's all. It's about replacing inclusion by calling. Thus we can simplify the hierarchy. If someone within his app wants to make hierarchical macro structure, it's easy to do this at app's global level, just similar to Kexi tables/queries structure in the Project Navigator by delivering something like virtual folders concept. sebsauer, 2006-03-31: Steps
^ toc Not all slots should be published for Manager::publishObject()
jstaniek, 2006-03-29: Perhaps we need to explicity publish each slot (security!). sebsauer, 2006-03-31: We could add a class that provides public slots for functionality like
jstaniek, 2006-03-31: You mean a wraper class that only exposes slots we want to expose to the public? My alternative cound be to: add a list of slot interfaces (written as strings). In the API this one could be: QStringList allowedInterfaces; allowedInterfaces << "KexiProject Then we can avoid a situation when lazy developers just pass internal QObject having slots not suitable for macros, and thus introduce security holes. The drawback is that, OTOH, they canforget about adding some interface strings to the list of allowed interfaces. sebsauer, 2006-04-01: We could provide QObject's to group different functionality.
Class Table : public QObject {
public slots:
void open(const QString& tablename) { ... }
void close(const QString& tablename) { ... }
};
This offers us on the one hand a more typesafe way to deal with functionality provided by Kexi (typos are checked by the compiler) and enables an easy way to handle publishing. At a later stage (lower priority) we could also need some describing i18n-text for each function. That could be done e.g. by using Q_PROPERTY. sebsauer, 2006-04-10: We need to limit the functionality. So, we should explicit pick Action's Kexi likes to provide on a list. At a first step I would suggest following actions;
sebsauer, 2006-05-14: We have following actions now;
Additional actions Kexi likes to offer;
^ toc Manager could handle the execution
jstaniek, 2006-03-29: Currently Action objects provide activate(). The idea is that since Manager want's to know about each action execution, we could move Action::activate() to Manager::execute(Macro&) or so. Action class and subclasses could stay just as something like action models, without a knowledge about executing context. Manager should care about executing. Thus, we can later extend the stuff to allow step-by-step execution, aka macro debugging. sebsauer, 2006-04-04: We are already able to add debugging (for a whole execution-chain) via the Context class. The Manager class needs to be extended to handle such cases more transparently. ^ toc Keep one place for handling XML
jstaniek, 2006-03-29: move QDomElement attributes e.g. from Action to XMLReader/XMLWriter. sebsauer, 2006-04-04: Steps
sebsauer, 2006-04-23: Declared done cause we are able to (un-)serialize with lib/xmlhandler.{h|cpp} now. ^ toc Nice-to-haveSome nice to have features. ^ toc Debugger
A debugger to debug Macros and control executions would be a nice feature. The KoMacro library could be extended to implement;
^ toc Kross-binding
Kross is the Scripting Framework used within Kexi to enable Python and Ruby scripting support. It would be nice, to be able to control Macros from within Kross. ^ toc Macrorecorder
A recorder to be able to record and replay performed actions. ^ toc Notes
|
|||||
|
||||||
