Stefan ,
Macro's can "live" in any document so also in a "Standalone form" , better
is to place your macro's in the LO application, who makes is fast more easy
to Update and distribute for several users as a extension.
Just curious, per a good practice, why the macros wouldn't be stored
on the server as other db objects (data)?
Why in the networked era, user needs to update their clients? We're in
post-networked era even.
Because Kexi does that by design. But here local file (reliable
sqlite3 that -based on reports- almost never crashes for users) is
handled in the same way as any server so there are no special cases.
Asking because of an intent to harmonize behaviours and approaches.
Because we are talking about office macros. An office macro is stored in
the user profle, in the install directory or in an office document.
Thanks for sharing the perspective. I'll explain the simple logic
that's a building block of data-oriented environments such as Kexi.
Macro in LO is an equivalent of an MS Access module, which is stored
in database, just like in Kexi.
It's also an equivalent of a stored procedure, which is stored in a
database, and in addition execution engine usually happens to be
bundled in the same product database and can be controlled using the
same channel as data, structure and triggers are controlled.
(Sorry if I am writing this under the eyes of seasoned (real) db users
but still I hope it will be useful to someone)
I don't need to mention that sharing authentication rules and
transmission channels with the database engine is beneficial for
security. Compare that to storing code in home directory, enabled for
free modification.
What you have up and running on your server is a database. The office
suite and the database are 2 completely separate things. The database
accepts requests and returns requested record sets without knowing any
of your queries, forms, reports and macros.
It accepts the exact same
requests from your web server returning the exact same record sets
without knowing anyting about your web server, script language or the
client's browser.
True, just like the database does not know that a NAME column's
semantics is "person's name".
It's the one or two upper layer(s) of your architecture that implement
the semantics.
Scripts/macros/forms/reports/query statements and everything else are
strings perfectly stored. Just like your bash scripts in a file
system. They are programs, stored as arrays of characters, without any
knowledge what's inside.
From that perspective, database is a storage medium, just like a file
system, with a different feature set.
For executing it you need an execution engine (javascript or python or
a clone of VB, etc.) and an execution context. Execution in an
environment itself calls a process call into being.
Ability of handling _programs_ on the server side is irrelevant to
ability of properly storing (textual, or binary) definition of
_macros_ and offering them to clients for retrieval, maybe versioning,
and protecting the access.
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
