Liking cljdoc? Tell your friends :D

automaton-core.adapters.commands-test

These tests are more or less always true (fail if an exception). Their value are to catch knowledge on how to use commands. And be able to watch bb log to check if results are as expected

These tests are more or less always true (fail if an exception).
Their value are to catch knowledge on how to use commands.
And be able to watch bb log to check if results are as expected
raw docstring

automaton-core.adapters.env-variables

Operating enviroment variables

Operating enviroment variables
raw docstring

automaton-core.adapters.regexp

Adapter to regular expressions Seamless access to regular expressions between cljs and clj Managing both back and frontend to have a seamless experience

Adapter to regular expressions
Seamless access to regular expressions between cljs and clj
Managing both back and frontend to have a seamless experience
raw docstring

automaton-core.adapters.schema

Validate the data against the schema. Is a proxy for malli

Validate the data against the schema.
Is a proxy for malli
raw docstring

automaton-core.adapters.string

String manipulation usable both in clj and cljs

String manipulation usable both in clj and cljs
raw docstring

automaton-core.adapters.time

Adapter to time functions.

Like formatting the date from #inst to str and way back Will be a proxy for clojure.instant, java.text.SimpleDateFormt

Adapter to time functions.

Like formatting the date from #inst to str and way back
Will be a proxy for `clojure.instant`, `java.text.SimpleDateFormt`
raw docstring

automaton-core.configuration

Configuration parameters, stored in configuration file. This namespace is the entry point to call conf

Design decision:

  • Configuration used to be based on outpace, it was too complicated for a small benefit,
  • The config.edn file was first unique, it needs to be updatable by environment to allow different value between production and repl, test and dev, but also monorepo vs app
  • The different version of parameter config.edn was first based on classpath (differentitated with aliases). It is ok for one app, but it renders the monrepo build complicated as it was naturally gathering all classpath, so all config.edn versions. The solution was to be based on environment parameter. So each alias can tell which version it uses, especially monorepo could be different.
Configuration parameters, stored in configuration file.
 This namespace is the entry point to call conf

Design decision:
* Configuration used to be based on outpace, it was too complicated for a small benefit,
* The `config.edn` file was first unique, it needs to be updatable by environment to allow different
value between production and repl, test and dev, but also monorepo vs app
* The different version of parameter `config.edn` was first based on classpath (differentitated
with aliases). It is ok for one app, but it renders the monrepo build complicated as it was naturally
gathering all classpath, so all `config.edn` versions. The solution was to be based on environment
parameter. So each alias can tell which version it uses, especially monorepo could be different.
raw docstring

automaton-core.configuration.environment

Get environment data stored in the configuration

Get environment data stored in the configuration
raw docstring

automaton-core.configuration.files

Namespace for simple configuration based on local file. Just like in core configuration, we are not using log nor outside dependencies to comply with the configuration requirements.

Namespace for simple configuration based on local file.
Just like in core configuration, we are not using log nor outside dependencies to comply with the configuration requirements.
raw docstring

automaton-core.core-test

Used to init test environment

Used to init test environment
raw docstring

automaton-core.dev

Will be refer :all in the subproject user namespace, default namepsace for subproject REPL

Linter doesn't detect that all that functions are callable from the user namespace of the repl.

Will be `refer :all` in the subproject `user` namespace, default namepsace for subproject REPL

Linter doesn't detect that all that functions are callable from the user namespace of the repl.
raw docstring

automaton-core.http.request

Namespace for http requests

Namespace for http requests
raw docstring

automaton-core.i18n.dict.text

Dictionary for translation of text in automaton-core

Is empty right now but will contain all translation factorized for all applications

Dictionary for translation of text in automaton-core

Is empty right now but will contain all translation factorized for all applications
raw docstring

automaton-core.i18n.language

All known languages in automaton-core, subsequent namespaces are forced to use only known languages there. Language concept could be enriched with language definition or other data, for instance, the flag of a language, ...

It is only a place for language description, not to tell where it is supposed to be used See cust-app themselves to know what language they use

All known languages in `automaton-core`, subsequent namespaces are forced to use only known languages there.
Language concept could be enriched with language definition or other data, for instance, the flag of a language, ...

It is only a place for language description, not to tell where it is supposed to be used
See cust-app themselves to know what language they use
raw docstring

automaton-core.i18n.missing-translation-report

Helper functions to test correctness of translation data including dictionaries

Helper functions to test correctness of translation data including dictionaries
raw docstring

automaton-core.i18n.translator

Protocol for translation logic

Protocol for translation logic
raw docstring

automaton-core.i18n.translator.tempura

Implementation of automaton-core.i18n.translator/Translator protocol with tempura

Is an adapter for translation in automaton-core, so no web related technology is mentionned there, even if tempura provides them. It will be the job of automton-web to provide that features

Implementation of `automaton-core.i18n.translator/Translator` protocol with [tempura](https://github.com/taoensso/tempura)

Is an adapter for translation in `automaton-core`, so no web related technology is mentionned there, even if tempura provides them.
It will be the job of `automton-web` to provide that features
raw docstring

automaton-core.log

Main entrypoint to automaton core logging, defines basic levels that we use to log.

Logical order of logs is: trace -> debug -> info -> warn -> error -> fatal

Design decision:

  • the log is relying on configuration namespace, so nothing will be logged before that
  • the log api is hosted in a cljc file so log is accessible to namespaces in cljc
    • Rationle:
      • deciding to push code in cljc should not prevent to log
      • postponing the decision to host code in frontend or backend is an objective
    • Consequence:
      • This namespace is the entrypoint for both clj and cljs implementations
Main entrypoint to automaton core logging, defines basic levels that we use to log.

Logical order of logs is:
trace -> debug -> info -> warn -> error -> fatal

Design decision:
* the log is relying on configuration namespace, so nothing will be logged before that
* the log api is hosted in a `cljc` file so log is accessible to namespaces in cljc
   * Rationle:
      * deciding to push code in cljc should not prevent to log
      * postponing the decision to host code in frontend or backend is an objective
   * Consequence:
      * This namespace is the entrypoint for both clj and cljs implementations
raw docstring

automaton-core.log.be-log

This namespace works as a backend proxy for chosing the logging implementation. Macros in this namespace to log are chosen from automaton-core.log. Current structure is generic for logging level, as they are the same right now in sense of this proxy. In future it may develop if needed to e.g. have the same number of macros as in automaton-core.log.

This namespace works as a backend proxy for chosing the logging implementation.
Macros in this namespace to log are chosen from `automaton-core.log`.
Current structure is generic for logging level, as they are the same right now in sense of this proxy.
In future it may develop if needed to e.g. have the same number of macros as in `automaton-core.log`.
raw docstring

automaton-core.log.be-registry

List of all known backend strategies

List of all known backend strategies
raw docstring

automaton-core.log.fe-log

Factory generating log function

Factory generating log function
raw docstring

automaton-core.log.fe-registry

List of all known frontend strategies

List of all known frontend strategies
raw docstring

automaton-core.log.impl.log4j2

It's a simple redirection to clojure tools logging Set to log4j2 check setup in

For more information read docs/tutorial/logging.md

It's a simple redirection to clojure tools logging
Set to log4j2 [check setup in](clojure/deps.edn)

For more information read docs/tutorial/logging.md
raw docstring

automaton-core.log.impl.print

Simple print namespace, most likely used just temporarily. trace -> debug -> info -> warn -> error -> fatal

Simple print namespace, most likely used just temporarily.
trace -> debug -> info -> warn -> error -> fatal
raw docstring

automaton-core.log.log-levels

Defines the possible log levels and their sequence

Defines the possible log levels and their sequence
raw docstring

automaton-core.log.registry

List all known strategies

List all known strategies
raw docstring

automaton-core.log.strategy

Strategy to choose what logger is used where and when

Strategy to choose what logger is used where and when
raw docstring

automaton-core.log.strategy.static-ns-level

Base strategy to statically define which logger to use

This strategy is a static one, it means it is applied at the compile time, so:

  • Any evolution of that strategy requires a new deployment.
  • All drop logs are not time consuming (except if the caller line makes some computation - which is the responsability of the caller)
  • All selected lines could then decide on runtime if there are needed or not. For instance log4j2 logger could use its own parameters to update dynamically which one is used or not

See automaton-core.log.strategy.static-ns-level/ns-rules for rule definition details

Base strategy to statically define which logger to use

This strategy is a static one, it means it is applied at the compile time, so:
* Any evolution of that strategy requires a new deployment.
* All drop logs are not time consuming (except if the caller line makes some computation - which is the responsability of the caller)
* All selected lines could then decide on runtime if there are needed or not. For instance log4j2 logger could use its own parameters to update dynamically which one is used or not

See `automaton-core.log.strategy.static-ns-level/ns-rules` for rule definition details 
raw docstring

automaton-core.log.tracking.be-error-tracking

Backend monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).

Backend monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).
raw docstring

automaton-core.log.tracking.be-sentry

Sentry backend implementation

Sentry backend implementation
raw docstring

automaton-core.log.tracking.fe-error-tracking

Automaton web monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).

Automaton web monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).
raw docstring

automaton-core.os.code-formatter

Format code Proxy to zprint

Format code
Proxy to [zprint](https://github.com/kkinnear/zprint)
raw docstring

automaton-core.portal.client

cljs

Client connection to the portal

Client connection to the portal
raw docstring

automaton-core.portal.common

Common setup for portal

Common setup for portal
raw docstring

automaton-core.portal.server

Portal server starting

Portal server starting
raw docstring

automaton-core.protocols.binary-relation

Test registry elements for binary relation properties

Test registry elements for binary relation properties
raw docstring

automaton-core.protocols.test-registry

Test registry for a protocol.

See ADR-0015

Test registry for a protocol.

See ADR-0015
raw docstring

automaton-core.repl

REPL component. Could be used remotely to connect on production or locally to connect a development environment

Design decision:

  • This REPL is available in automaton-core.repl for enabling the repl for local acceptance and production
  • This namespace rely on automaton-core.configuration, which means no log could be done before configuration is loaded
REPL component. Could be used remotely to connect on production or locally to connect a development environment

Design decision:
* This REPL is available in `automaton-core.repl` for enabling the repl for local acceptance and production
* This namespace rely on `automaton-core.configuration`, which means no log could be done before configuration is loaded
raw docstring

automaton-core.repl.entry-point

REPL entry point

REPL entry point
raw docstring

automaton-core.storage.impl.datomic.datomic

Implementation of storage protocols in datomic

Implementation of storage protocols in datomic
raw docstring

automaton-core.storage.impl.datomic.schema

Contains datomic schema

Contains datomic schema
raw docstring

automaton-core.storage.impl.datomic.utils

Datomic utility functions

Datomic utility functions
raw docstring

automaton-core.storage.persistent

Protocol namespace defining what is required from persistent storage implementation.

Protocol namespace defining what is required from persistent storage implementation.
raw docstring

automaton-core.url

Url management See lambdaisland.uri for useful functions And see the RFC for references

Url management
See [lambdaisland.uri](https://cljdoc.org/d/lambdaisland/uri/1.15.125/doc/readme) for useful functions
And see the [RFC](https://www.ietf.org/rfc/rfc3986.txt) for references
raw docstring

automaton-core.user.account.datalog

Usefull datalog queries to be used with access protocol functions

Usefull datalog queries to be used with access protocol functions
raw docstring

automaton-core.user.account.persistence

Account access entrypoint functions.

Account access entrypoint functions.
raw docstring

automaton-core.user.account.schema

Contains all schema related to user accounts

Contains all schema related to user accounts
raw docstring

automaton-core.utils.date

Utility function for date management

Utility function for date management
raw docstring

automaton-core.utils.keyword

Utility functions for keywords.

Utility functions for keywords.
raw docstring

automaton-core.utils.pretty-print

Gathers functions related to pretty printing or pretty formatting.

Gathers functions related to pretty printing or pretty formatting.
raw docstring

automaton-core.utils.sequences

Manipulation of sequences

Manipulation of sequences
raw docstring

automaton-core.utils.string-to-id

Transform a string into an id That id are currently used and tested for React

Transform a string into an id
That id are currently used and tested for React
raw docstring

automaton-core.utils.type-arg

Force arguments to comply to a protocol

Design decision

  • Arguments typed can be asserted
    • Rationale:

      • By default functional programming does not require typing of arguments. But the assembly of many different components may lead to difficult debugging, as the failing will occur deep in the call stack. Without a good understanding of the implementation, the error's understanding may be difficult. So the solution is to assert the arguments type.
      • This is concept usually used in Object Oriented Programming, but Hephaistox believes OOP's principle are useful, the point is to apply it where we need it, and not everywhere as most of the OOP language requires.
      • We believe our components assembly solutions will need these assertion to robustify the code and accelerate the development cycle
    • Consequences:

      • the asserts functions below should be called by the implementations build function
      • if the argment is not compliant, it is explicitly refused and the build function returns nil
    • Limit

      • The assert is time consuming during optimization phase. So it is done only on development environment, through a macro mechanism which is skipping that assertion implementation
      • The this argument of a defrecord (i.e. the first argument) couldn't be tested in the implementation as clojure needs a valid object to be able to call the method on it.
      • As described below, this mechanism if implemented for clojure compiler only
    • Assert-protocol is not implemented on clojurescript

    • Rationale: The solution is based on extends? which is not compatible with clojurescript as for now (cf. clojurescript doc)

    • Consequence:

      • This tests will only be checked during clojure test, which is not an issue if that assemblies are done in cljc side
      • All assert will return true on clojurescript
      • The assert-protocol function has a :unused-binding flag to prevent kondo warnings
Force arguments to comply to a protocol

Design decision
* Arguments typed can be asserted
   * Rationale:
       * By default functional programming does not require typing of arguments. But the assembly of many different components may lead to difficult debugging, as the failing will occur deep in the call stack. Without a good understanding of the implementation, the error's understanding may be difficult. So the solution is to assert the arguments type.
       * This is concept usually used in Object Oriented Programming, but Hephaistox believes OOP's principle are useful, the point is to apply it where we need it, and not everywhere as most of the OOP language requires.
       * We believe our components assembly solutions will need these assertion to robustify the code and accelerate the development cycle
   * Consequences:
      * the asserts functions below should be called by the implementations build function
      * if the argment is not compliant, it is explicitly refused and the build function returns nil
   * Limit
      * The assert is time consuming during optimization phase. So it is done only on development environment, through a macro mechanism which is skipping that assertion implementation
      * The `this` argument of a `defrecord` (i.e. the first argument) couldn't be tested in the implementation as clojure needs a valid object to be able to call the method on it.
      * As described below, this mechanism if implemented for clojure compiler only

  * Assert-protocol is not implemented on clojurescript
   * Rationale: The solution is based on `extends?` which is not compatible with clojurescript as for now (cf. [clojurescript doc](https://clojurescript.org/about/differences#_protocol))
   * Consequence:
       * This tests will only be checked during clojure test, which is not an issue if that assemblies are done in cljc side
       * All assert will return true on clojurescript
       * The `assert-protocol` function has a `:unused-binding` flag to prevent kondo warnings
raw docstring

automaton-core.utils.uuid-gen

Generate uuid, is a proxy to http://danlentz.github.io/clj-uuid/

Generate uuid, is a proxy to `http://danlentz.github.io/clj-uuid/`
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close