freeradiantbunny Agent Classes
The freeradiantbunny software exists to help aid people who are growing food with a permaculture design method.
To achieve this we design. And, at the core of our design is a set of classes which model the abstract problem domain.
You heard right!
There is a set of classes, call them "agent classes" and let each of these classes be accessed by the user, thus representing a kind of view upon the data of the database, a view comprised of the lens of the classes.
More importantly however:, each of these classes is represented by a database table.
Enter multiple perspectives.
At one level, the perspective is whole purpose of the classes.
The classes explicit API compiles to be efficiently run by the central processing unit.
The machine is optimized for the classes and the classes takes advantage of the database management system.
The books talk about the CRUD of the database. But, for me, with postgresql, I estimate the concept should be referred to as ISUD, silly as that may sound.
So, this is our first truism, that each Agent Classes should have a corresponding database table.
This design guideline is a way of specifying some code for the database, creating a concept that says an Agent Class is associated with a Rust file. A file of code. With a compiler at the ready.
The names differ across the design. In some places the names are all in lowercase. In some places the capitalization of a letter happens. The names are important not only because it becomes a common reference to a design, but also as a word that is searched for amongst the data of the file.
The matching is important because a given classes file is an API to its corresponding database table. Enter syntax. And, the rules of rules.
That certain traits are common upon all Agent Classes means that there is a class library of parent classes that each Agent Classes inherits to different degrees.
A very plain starter classes awaits us, too. Each classes is considered to be the child of the scrubber class, the parent class. By following some basic functions, an agent has access to the patterns shared across the community. The database stores data is way that ensures us about the nature of the information, the datatypes and the constraints. The database management system serves to enforce the filtering out of certain types of erroneous data, leaving data that is qualified and extremely namable.
The Structured Query language helps us here. SQL should be known well, because relationships can be exquisitely express.
The scrubber classes is an empirical conduit of data moving inward and outward.
In addition, the text description of each classes may be stored in a file on the file system. Typically a daily backup of the database is stored in a file of SQL. And, the data could have been output to a a file using psql >\o command.
Between database tables and software classes, and computer files with Rust code, and the help of an enter Internet, between all these, is a word of wonder to be discover. In this way each agent class has many aspects, perhaps infinitely designable aspects.
Each with its own context inside out networked computers.
Let us also approach our worldly projects with alacrity and sisu.
List of freeradiantbunny Agent Classes
The agent classes are listed in the table below. As of database schema 1.6, there are 111 tables in the database. Speaking SQL then one might say:
select count(*) from information_schema.tables where table_schema = 'public';
The list below also serves as a menu to the agent class documentation. Click on the name (or id if available) and you should be presented with the documentation for that given agent class.
Related Information
From here, there are two ways in which you could go:
- larger scope
- smaller scope
Larger Scope: Check out the Directories
To go larger scope, you could check out the over-all design of the files in the application, of which the agent class files (described on this page) are just a part. To understand that larger scope, check out the directories.
Said another way: this page described just one type of file in the application. To learn more about all of the files in the application, visit the directories.
Smaller Scope: Check out the Subsystems
To go smaller scope, you could check out the subsystems. Instead of viewing all of the Agent Classes, view a subset of the Agent Classes as selected by designer-assigned "subsystem" categorization.
This small scope was developed based upon the divide and conquere tactic. To aid the person learning the Agent Classes, the classes have been grouped. The agents have been categorized into subsystems based upon the natural qualities of the classes and how they work together. The subsystem categorizaing aims to aid the learning of the classes by making it easier to mentally manage a large list of agent classes. So, if you are aiming to learn the Agent Classes list, you could visit subsystems.
Or, if you wanted to jump that step, you could go directly to one of the subsystems. Check out the subsystems and dive right into learning about a particular subsystem.
The most important tables in the database contain the projects and goal_statements data.
Using the Motivation Model as a design theory, tables for business_plant_texts and processes round out the core data of an initiative.
Then the processes are brought to action with the scene_elements table.
To learn about these classes, visit the Motivational Model Subsystem.
last updated: 2023-09-29