Architecture - Revision history

LegacyKing: /* Future */

2023-06-22T22:10:42Z

‎Future

Tom Parker at 04:14, 27 February 2018

2018-02-27T04:14:03Z

Tom Parker: /* Rules Persistence System */

2018-02-25T22:18:54Z

‎Rules Persistence System

Tom Parker: /* A Day in the Life of PCGen */

2018-02-25T22:17:22Z

‎A Day in the Life of PCGen

Tom Parker at 22:14, 25 February 2018

2018-02-25T22:14:49Z

Tom Parker at 22:11, 25 February 2018

2018-02-25T22:11:01Z

Tom Parker at 20:31, 25 February 2018

2018-02-25T20:31:12Z

Tom Parker: /* Current */

2018-02-04T00:02:03Z

‎Current

Tom Parker: /* Past Projects */

2016-02-25T01:19:05Z

‎Past Projects

Tom Parker: /* Current */

2016-02-25T01:18:51Z

‎Current

@@ Line 111: / Line 111: @@
 * [[Bonus Subsystem Thoughts]]
 * [[Bonus Subsystem Design]]
 =Past Projects=

@@ Line 42: / Line 42: @@
 Given the combination of Loader (file format) and Token, we can look up the appropriate plugin to process that specific token.  This is called to parse the value of the token.  This parse method is responsible for loading the information about the token into the Rules Data Store (generally into the object being loaded, but this is not universally true).  Any failure means the entire contents of the token will be ignored (the contents of the token are a "transaction" in the sense that it fully succeeds or fully fails).
-This includes [[CDOM References Concept Document|CDOMReferences]] and the [[Load Commit Subsystem]]
+Those tokens may encounter various items including references to other objects, which we capture as [[CDOM References Concept Document|CDOMReferences]].  In addition, there may be groups of objects referred to as well, so you may want to learn about [[Referring to Groups in LST Data]].
 ==Rules Data Store==
@@ Line 49: / Line 51: @@
 As a "Data Store", it is very much akin to a complicated database (it could be converted into an actual database with some effort). The Rules Data Store is not designed to have methods that interpret the contents of the Rules Data Store, nor is the Rules Data Store capable of storing the information it contains into a persistent state. The conversion to and from a persistent state is owned by the [[Rules Persistence System]].
 =Other - to Be Edited=
-** Player Character UI: The <i>Player Character UI</i> is responsible for presenting the user with the contents of the PC, including all of the PC's characteristics.  Requests to modify a PC are sent to the <i>Character Editor</i> system for action.
-** Character Editor: The <i>Character Editor</i> system is responsible for providing the capability to modify the PC.  Changes to the PC are communicated to the <i>Event Controller</i> as well as written into the <i>Character Data Store</i>.
 ** Character Persistence: The <i>Character Persistence</i> system is responsible for loading and saving PCs into the specified file format. The <i>Character Persistence</i> system is also responsible for creating and initializing a new Player Character.
 ** Character Output: The <i>Character Output</i> system is responsible for resolving the active objects on a PC, searching those objects to find specific information, and preparing that information for consumption by any of the systems that desire PC information.
@@ Line 60: / Line 79: @@
 * [[Explanation of the Code Base|Code Base]] - Key Concepts
 ** [[Key Terms]]
 ** [[Tags and Tokens]]
 ** [[FreeMarker Output]]
 ** [[CDOM References Concept Document]]
-** [[CDOM Primitive Choice Set Concept Document]]
+* [[CDOM Primitive Choice Set Concept Document]]
 ** [[CDOM Choice Actors Concept Document]]

@@ Line 42: / Line 42: @@
 Given the combination of Loader (file format) and Token, we can look up the appropriate plugin to process that specific token.  This is called to parse the value of the token.  This parse method is responsible for loading the information about the token into the Rules Data Store (generally into the object being loaded, but this is not universally true).  Any failure means the entire contents of the token will be ignored (the contents of the token are a "transaction" in the sense that it fully succeeds or fully fails).
-This includes [[CDOMReferences|CDOM References Concept Document]] and the [[Load Commit Subsystem]]
+This includes [[CDOM References Concept Document|CDOMReferences]] and the [[Load Commit Subsystem]]
 ==Rules Data Store==

@@ Line 16: / Line 16: @@
 There is an [[Index to Architecture Documents]] that provides a complete list and is in the recommended reading order for those who wish to read the complete set of relevant documentation.
-=A Day in the Life of PCGen=
+=PCGen Subsystems=
 This section lays out the primary sub-systems within PCGen
@@ Line 49: / Line 49: @@
 As a "Data Store", it is very much akin to a complicated database (it could be converted into an actual database with some effort). The Rules Data Store is not designed to have methods that interpret the contents of the Rules Data Store, nor is the Rules Data Store capable of storing the information it contains into a persistent state. The conversion to and from a persistent state is owned by the [[Rules Persistence System]].
 =Other - to Be Edited=

@@ Line 3: / Line 3: @@
    |}
 =Introduction=
 Welcome to the Wiki section for the Architecture team!
@@ Line 10: / Line 11: @@
 Before reading about the details of the PCGen architecture, it is likely helpful to understand our key [[Design Concepts for PCGen]] and [[Architecture Document Conventions]]
 =A Day in the Life of PCGen=
@@ Line 37: / Line 42: @@
 Given the combination of Loader (file format) and Token, we can look up the appropriate plugin to process that specific token.  This is called to parse the value of the token.  This parse method is responsible for loading the information about the token into the Rules Data Store (generally into the object being loaded, but this is not universally true).  Any failure means the entire contents of the token will be ignored (the contents of the token are a "transaction" in the sense that it fully succeeds or fully fails).
-=Other - to Be Edited=
+As a "Data Store", it is very much akin to a complicated database (it could be converted into an actual database with some effort). The Rules Data Store is not designed to have methods that interpret the contents of the Rules Data Store, nor is the Rules Data Store capable of storing the information it contains into a persistent state. The conversion to and from a persistent state is owned by the [[Rules Persistence System]].
-*** [[Load Commit Subsystem]]
+=Other - to Be Edited=
 ** Character Editor: The <i>Character Editor</i> system is responsible for providing the capability to modify the PC.  Changes to the PC are communicated to the <i>Event Controller</i> as well as written into the <i>Character Data Store</i>.
 ** Character Persistence: The <i>Character Persistence</i> system is responsible for loading and saving PCs into the specified file format. The <i>Character Persistence</i> system is also responsible for creating and initializing a new Player Character.
 ** Character Output: The <i>Character Output</i> system is responsible for resolving the active objects on a PC, searching those objects to find specific information, and preparing that information for consumption by any of the systems that desire PC information.
 ** Event Controller: The <i>Event Controller</i> acts as a hub to communicate events (typically triggered by changes to a PC) to the UI and to any loaded Plugins.
 ** Character Data Store: The <i>Character Data Store</i> is the internal data structure used to store the PC.

@@ Line 3: / Line 3: @@
    |}
 =Introduction=
 Welcome to the Wiki section for the Architecture team!
-=Mission Statement=
+This section of our wiki will explain the different portions of our code base, the current work underway to improve different sections for better performance and flexibility.
 =Resources=
-* Key [[Design Concepts for PCGen]]
+Before reading about the details of the PCGen architecture, it is likely helpful to understand our key [[Design Concepts for PCGen]] and [[Architecture Document Conventions]]
-* Systems within PCGen [[Image:Overall_system_figure.png|frame|Block diagram of proposed CDOM structure]]
+=A Day in the Life of PCGen=
-** Load UI: The <i>Load UI</i> is responsible for presenting the user with the options of game systems and components available to be loaded.  The LoadUI triggers a call to the <i>Rules Persistence</i> system when the user requests for specific data to be loaded, and to the <i>Character Persistence</i> system when the user requests for a Player Character to be loaded..
-** Editor UI: The <i>Editor UI</i> is responsible for presenting the user with the contents of the <i>Rules Data Store</i>.  It communicates requests to change the contents of the <i>Rules Data Store</i> to the <i>Rules Editor</i> system.
+This section lays out the primary sub-systems within PCGen
 ** Player Character UI: The <i>Player Character UI</i> is responsible for presenting the user with the contents of the PC, including all of the PC's characteristics.  Requests to modify a PC are sent to the <i>Character Editor</i> system for action.
-** [[Startup System]]: The <i>Startup System</i> is responsible for the activities required to load PCGen to the state where a user can select an option from the <i>Load UI</i>. This includes discovery of Plugins.
-** [[Rules Persistence System|Rules Persistence]]: The <i>Rules Persistence</i> system is responsible for loading game system and component data from the data file format and saving it back into that data file format.
 *** [[Arch. Discuss of Plugin System|The Persistence Plugin System]]
 *** [[Load Commit Subsystem]]

@@ Line 53: / Line 53: @@
 * [[LST Token Information]] (scratchpad - relates to facet design and abstracting behaviors)
 * [[BONUS Tag conversion list]]
 ==Future==

@@ Line 65: / Line 65: @@
 =Past Projects=
 * [[Architecture Update 1Q2013]]
 * [[Subsystem Isolation]] (out of date?)

@@ Line 47: / Line 47: @@
 ==Current==
-* [[Formula Parser Equip Vars Demo]] based on [[Formula Parser Equip Vars Proposal]] which includes [[Formula Parser-JEP removal]] (sandbox) and [[Formula Parser Conversion Instructions]]
+* [[Formula System Conversion]]
-* [[FACT Token]], [[FACTSET Token]], [[FreeMarker Facet Output]]
+* [[FreeMarker Facet Output]]
 * [[Incompatible Change List v6]]
 * [[Current Architecture Projects]] (personal scratchpad)