Metadata-Version: 2.4
Name: ll-la
Version: 0.67.0
Summary: Python API for LivingApps
Home-page: http://github.com/LivingLogic/LivingApps.Python.LivingAPI
Author: Walter Doerwald
Author-email: walter@livinglogic.de
License: MIT
Keywords: LivingApps
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Programming Language :: Python :: 3.14
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Requires-Python: >=3.14
License-File: LICENSE.txt
Requires-Dist: ll-xist>=5.90.1
Requires-Dist: requests>=2.21.0
Requires-Dist: geocoder>=1.30.1
Requires-Dist: Pillow>=6.1.0
Requires-Dist: validators>=0.18.2
Provides-Extra: db
Requires-Dist: oracledb>=26.0.0; extra == "db"
Requires-Dist: psycopg[binary]>=3.3.0; extra == "db"
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: home-page
Dynamic: keywords
Dynamic: license
Dynamic: license-file
Dynamic: provides-extra
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

``ll.la`` provides a Python API for the LivingApps system
(see http://www.living-apps.de/ or http://www.living-apps.com/ for more info).

``ll.la`` allows you to fetch the configured data sources from a template,
create new records, and update and delete existing records all from your Python
prompt (or script).

For more info about LivingApps and this Python SDK, see
https://my.living-apps.de/docs/PythonSDK.html (in german).


0.67.0 (2026-11-04)
-------------------

* The template library is now versioned. The new class ``TemplateLibrary``
  describes one version of the library with the attributes ``id``,
  ``version``, ``label``, ``description``, ``templates`` (the templates of
  this version, keyed by identifier, or ``*.<type>.<identifier>`` for typed
  templates) and ``parameters`` (the parameters of this version, keyed by
  identifier). The last two are ``None`` when the version has been loaded
  without its templates and parameters.

* ``Globals`` has two new attributes: ``template_libraries`` is a dictionary
  mapping version numbers to the ``TemplateLibrary`` objects of all versions
  (without their templates and parameters). ``template_library_version`` is
  the version whose templates and parameters are used by the running
  template (i.e. for ``globals.templates``, ``app.templates``,
  ``record.templates`` etc. and for the library parameters in
  ``globals.params`` and ``app.params``). It is read-only and is
  ``app.template_library_version`` (or the default version of the system
  if there's no app).

* ``App`` has a new attribute ``template_library_version`` that contains
  the template library version the app uses. It can be set (to a version
  that exists in ``globals.template_libraries``) and is saved by
  ``App.save()`` (this requires the new parameter ``p_tl_version`` of
  ``livingapi_pkg.template_update``).

* The handler methods ``fetch_librarytemplates()`` and
  ``fetch_libraryparams()`` have been replaced by ``fetch_templatelibrary()``
  (the version used by a ``Globals`` object, with templates and parameters),
  and ``fetch_templatelibraries()`` (all versions, without templates and
  parameters). The ``DBHandler`` implements them via the new Postgres
  functions ``templatelibrary.templatelibrary_ful4on()`` and
  ``templatelibrary.templatelibraries_ful4on()``.

* ``User`` has a new attribute ``colorscheme`` that contains the preferred
  browser color scheme of the user as a ``User.ColorScheme`` enum (``LIGHT``,
  ``DARK`` or ``AUTO``; ``"light"``, ``"dark"`` or ``"auto"`` in UL4; the
  default for dumps from an older database is ``AUTO``). It is also available
  as ``user.colorscheme`` in vSQL expressions.

* The vSQL variables for the vSQL expressions of a ``DataSourceConfig``
  (``appfilter``, ``recordfilter`` and the order expressions), a
  ``DataSourceChildrenConfig`` (``filter`` and its order expressions), a
  ``DataAction`` (``filter``), a ``DataActionCommand`` (``condition``) and a
  ``DataActionDetail`` (``expression``) are now defined in Python by the new
  methods ``vsqlvars_appfilter()``, ``vsqlvars_recordfilter()``,
  ``vsqlvars_filter()``, ``vsqlvars_condition()`` and
  ``vsqlvars_expression()`` instead of being fetched from the database
  functions of ``vsqlsupport_pkg3`` (which no longer exist). ``VSQLAttr`` no
  longer has a ``function`` argument, and the ``DBHandler`` method
  ``save_vsql_source()`` takes the dictionary of vSQL variables instead of the
  name of a database function (and no additional keyword arguments).

* ``App`` has new methods for creating vSQL fields: ``vsqlfield_record()``
  (for a single record of the app), the static methods
  ``vsqlfield_records_common()``, ``vsqlfield_record_common()`` and
  ``vsqlfield_app_common()`` (for an unknown app), ``vsqlfield_user()`` (for
  the logged in user) and ``vsqlgroup_app_common()`` (the vSQL group of an
  unknown app). The vSQL variable ``record`` (the detail record) in the
  ``DBHandler`` methods that fetch records now references a single record
  (instead of the records of its app).

* The class attributes ``HTTPRequest.vsqlgroup`` and ``HTTPRequest.vsqlfield``
  have been removed. The vSQL variable ``params`` no longer exists; request
  parameters are accessed via the vSQL functions ``request_param_str()``,
  ``request_param_int()`` etc. instead.

* ``App.params`` and ``AppGroup.params`` no longer fail with handlers that
  can't load parameters incrementally (like the ``HTTPHandler``): The
  parameters are now loaded via the handler methods
  ``app_params_incremental_data()`` and ``appgroup_params_incremental_data()``
  (implemented by ``DBHandler``), and parameter sets that can't be loaded
  (e.g. the app group parameters) are skipped.

* ``App.vsqlgroup_app`` now contains a field ``p_<identifier>`` for each
  parameter of the app (via the new properties ``AppParameter.vsqlfield``
  and ``AppParameter.vsqlgroup``), so that vSQL expressions like
  ``app.p_foo.value`` can be compiled again. The field ``app`` of the vSQL
  group for records (``App.vsqlgroup_records``) now references the vSQL
  group of the app, so ``r.app.name`` or ``r.app.p_foo.value`` work too.

* The fields of the vSQL groups ``File.vsqlgroup``, ``User.vsqlgroup`` and
  ``Installation.vsqlgroup`` now include the table alias, so that joining
  two files or two users in one query (e.g. ``r.createdby.email ==
  r.updatedby.email``) no longer produces ambiguous column references.

* ``File.vsqlgroup`` now uses the view ``upload_ref_upload_select`` (which
  contains the columns of ``upload``; ``upload_ref_select`` doesn't), so
  that file attributes like ``filename`` or ``mimetype`` can be used in
  vSQL expressions that are rendered by Python. The field ``id`` has been
  removed, since the id of a file is not a database column (the database
  doesn't support it in vSQL either). The joins to the file of
  ``user.image`` and of an app parameter of type ``upload`` are outer joins
  now, so that users and parameters without a file no longer vanish from
  the result when the expression references the file.

* The vSQL group of an app has the new fields ``image`` (the app image as a
  file) and ``appgroup`` (the app group, via the new class attribute
  ``AppGroup.vsqlgroup`` with the fields ``id``, ``name``, ``description``,
  ``image``, ``createdat``, ``createdby``, ``updatedat`` and ``updatedby``).

* The field ``internalid`` has been removed from ``Installation.vsqlgroup``.
  It referenced the column ``upl_id``, which ``installation_link`` doesn't
  have, and the database doesn't support it in vSQL either.


