2023.1:Node Tree (UI Element) - Revision history

Dgreenwood at 15:41, 4 September 2025

2025-09-04T15:41:03Z

← Older revision		Revision as of 10:41, 4 September 2025
Line 1:		Line 1:
	~~{{WIP}}~~

	{{AutoVersion}}		{{AutoVersion}}

Line 6:		Line 4:

	Resources are created in Grooper by adding new "nodes" to the Node Tree. The Node Tree is called a "tree", because it "branches." Each new node added under another creates a new "branch", or a new level down from the node it is created. What node types can be added under a branch are determined by the node(s) above it.		Resources are created in Grooper by adding new "nodes" to the Node Tree. The Node Tree is called a "tree", because it "branches." Each new node added under another creates a new "branch", or a new level down from the node it is created. What node types can be added under a branch are determined by the node(s) above it.

			== How do I access the Node Tree? ==

			The Node Tree is accessed from the '''Design''' page. More information on navigating the Node Tree and the Design page are found in the [[Design Page]] article.

	== Grooper Nodes ==		== Grooper Nodes ==

Dgreenwood: /* Grooper Nodes */

2025-09-04T15:38:03Z

Grooper Nodes

@@ Line 42: / Line 42: @@
 * These different branches create the Node Tree's hierarchical structure.
 <br clear=all>
 === What's the difference between a node and an object? ===

Dgreenwood: /* Node Types */

2025-09-04T15:37:39Z

Node Types

← Older revision		Revision as of 10:37, 4 September 2025
Line 81:		Line 81:

	'''''BE AWARE:''''' Because "object" is a very general term, many people use the terms "node" and "object" interchangeably (and, after all, a node is a type of object). You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".		'''''BE AWARE:''''' Because "object" is a very general term, many people use the terms "node" and "object" interchangeably (and, after all, a node is a type of object). You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".

	~~=== Node Types ===~~

	~~Node Types include any configuration object you can add to the Grooper Node Tree. This includes:~~
	* Projects
	* Batch Processes and Batch Process Steps
	* Batches (and other Batch Objects)
	* Content Models (and other Content Types)
	* Data Types (and other Extractor Types)
	* And more

	~~A full list of Grooper Node Types can be found in the [[Glossary#Node Types\|Node Types]] section of the Glossary article.~~

	=== More on parents and children ===		=== More on parents and children ===

Dgreenwood: /* Nodes vs Embedded Objects */

2025-09-04T15:37:08Z

Nodes vs Embedded Objects

← Older revision		Revision as of 10:37, 4 September 2025
Line 56:		Line 56:
	<br clear=all>		<br clear=all>

	=== Nodes vs Embedded Objects ===		==== Nodes vs Embedded Objects ====

	All nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded Objects" are configurable objects owned by another object. The exist as part of a larger configuration, such as a node's configuration. Embedded objects are encountered and configured when editing properties in a node's Property Grid.		All nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded Objects" are configurable objects owned by another object. The exist as part of a larger configuration, such as a node's configuration. Embedded objects are encountered and configured when editing properties in a node's Property Grid.

Dgreenwood: /* What's the difference between a node and an object? */

2025-09-04T15:36:27Z

What's the difference between a node and an object?

@@ Line 46: / Line 46: @@
 An "object" is a very general computer programming term. It refers to self-contained entities that form the building blocks of modern programming.
-A "node" is specific kind of object in Grooper. It is something add to the Node Tree. What that node is and what it's for is defined by their "Node Type"
+A "node" is specific kind of object in Grooper. They are configuration objects added to the Node Tree. They let Grooper Design users configure settings and/or store data necessary for Grooper's document processing. What that node is and what it's for is defined by their "[[#Node Types|Node Type]]"
 <br>
 [[File:2023.1 Grooper-Node-02.png|left]]
@@ Line 56: / Line 56: @@
 <br clear=all>
-Furthermore, all nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded objects" are often found in a node's property grid.
+=== Nodes vs Embedded Objects ===
-For example, '''Data Field''' nodes have a "Value Extractor" property. Value Extractors, such as [[Pattern Match]] and [[Labeled Value]], are themselves objects. They are "embedded objects" in that they can be embedded into a property of a node.
+All nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded Objects" are configurable objects owned by another object. The exist as part of a larger configuration, such as a node's configuration. Embedded objects are encountered and configured when editing properties in a node's Property Grid.
-'''''BE AWARE:''''' Because "object" is a very general term, and a "node" is a type of object, many people use the terms "node" and "object" interchangeably.  You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".
+Example 1:
 === More on parents and children ===

Dgreenwood at 17:03, 28 April 2025

2025-04-28T17:03:19Z

← Older revision		Revision as of 12:03, 28 April 2025
Line 5:		Line 5:
	<blockquote>{{#lst:Glossary\|Node Tree}}</blockquote>		<blockquote>{{#lst:Glossary\|Node Tree}}</blockquote>

	Resources are created in Grooper by adding new "nodes" to the Node Tree. The Node Tree is called a "tree", because it "branches." Each new node added under another creates a new "branch", or a new level down from the node it is created. What ~~object~~ types can be added under a branch are determined by the node(s) above it.		Resources are created in Grooper by adding new "nodes" to the Node Tree. The Node Tree is called a "tree", because it "branches." Each new node added under another creates a new "branch", or a new level down from the node it is created. What node types can be added under a branch are determined by the node(s) above it.

	== Grooper Nodes ==		== Grooper Nodes ==
	Any single item in the Node Tree is a '''Grooper Node''' (also simply referred to as a "node"). Each node has a ~~'''''~~Node ~~Object~~ Type~~'''''~~, which defines what that node is, how it is configured and used throughout the Grooper Repository. For example, a '''Batch''' is the ~~''''Node Object Type''''' (often just called~~ "~~object~~") that serves as the fundamental document container in Grooper.		Any single item in the Node Tree is a '''Grooper Node''' (also simply referred to as a "node"). Each node has a "Node Type", which defines what that node is, how it is configured and used throughout the Grooper Repository. For example, a '''Batch''' is the "node type" that serves as the fundamental document container in Grooper.

	Each new node creates a new branch under an existing one, creating the hierarchical structure of the tree.		Each new node creates a new branch under an existing one, creating the hierarchical structure of the tree.
Line 23:		Line 23:
	At the top of the '''[[Grooper Repository]]''' is the '''[[Root]]''' node (aka the "'''Grooper Root'''").		At the top of the '''[[Grooper Repository]]''' is the '''[[Root]]''' node (aka the "'''Grooper Root'''").

	Under the '''Root''' node, there are six main child nodes in the Node Tree. These nodes ~~serve the purpose of organizing~~ Grooper nodes according to their ~~object~~ type to assist Node Tree navigation.		Under the '''Root''' node, there are six main child nodes in the Node Tree. These nodes organize all Grooper nodes according to their node type to assist Node Tree navigation.

	* '''Batches'''		* '''Batches'''
Line 56:		Line 56:
	<br clear=all>		<br clear=all>

	~~All~~ nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded objects" are often found in a node's property grid.		Furthermore, all nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded objects" are often found in a node's property grid.

	For example, '''Data Field''' nodes have a "Value Extractor" property. Value Extractors, such as [[Pattern Match]] and [[Labeled Value]], are themselves objects. They are "embedded objects" in that they can be embedded into a property of a node.		For example, '''Data Field''' nodes have a "Value Extractor" property. Value Extractors, such as [[Pattern Match]] and [[Labeled Value]], are themselves objects. They are "embedded objects" in that they can be embedded into a property of a node.

Dgreenwood: /* More on parents and children */

2025-04-28T17:00:03Z

More on parents and children

Dgreenwood: /* What's the difference between a node and an object? */

2025-04-28T16:58:53Z

What's the difference between a node and an object?

← Older revision		Revision as of 11:58, 28 April 2025
Line 44:		Line 44:

	=== What's the difference between a node and an object? ===		=== What's the difference between a node and an object? ===
			An "object" is a very general computer programming term. It refers to self-contained entities that form the building blocks of modern programming.

			A "node" is specific kind of object in Grooper. It is something add to the Node Tree. What that node is and what it's for is defined by their "Node Type"
	<br>		<br>

	[[File:2023.1 Grooper-Node-02.png\|left]]		[[File:2023.1 Grooper-Node-02.png\|left]]

	~~A "node" is something you add to the Node Tree. Every node has an object type. An "object" is the type of thing that node is.~~

	For Example: Here, there are three nodes named "Name" "DOB" and "SSN".		For Example: Here, there are three nodes named "Name" "DOB" and "SSN".
	<ul style="margin-left:440px">		<ul style="margin-left:440px">
	<li>These are individual nodes in the Node Tree.</li>		<li>These are individual nodes in the Node Tree.</li>
	<li>However they share the same ~~object type~~. They are all '''Data Fields'''.</li>		<li>However they share the same Node Type. They are all '''Data Fields'''.</li>
	</ul>		</ul>
			<br clear=all>

	~~<br clear=~~all>		All nodes are objects, but not all objects are nodes. Objects are just re-usable chunks of code. "Embedded objects" are often found in a node's property grid.

			For example, '''Data Field''' nodes have a "Value Extractor" property. Value Extractors, such as [[Pattern Match]] and [[Labeled Value]], are themselves objects. They are "embedded objects" in that they can be embedded into a property of a node.

	'''''BE AWARE:''''' ~~The terms~~ "~~node~~" and "object~~" are so similar~~ many people use the terms interchangeably. You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".		'''''BE AWARE:''''' Because "object" is a very general term, and a "node" is a type of object, many people use the terms "node" and "object" interchangeably. You will probably even find occurrences in the Grooper Wiki where we refer to a "node" as an "object".

	=== More on parents and children ===		=== More on parents and children ===

Dgreenwood: Dgreenwood moved page Node Tree (UI Element) to 2023.1:Node Tree (UI Element)

2025-03-03T17:36:27Z

Dgreenwood moved page Node Tree (UI Element) to 2023.1:Node Tree (UI Element)

← Older revision	Revision as of 12:36, 3 March 2025
(No difference)

Randallkinard at 14:57, 22 November 2024

2024-11-22T14:57:19Z

← Older revision		Revision as of 09:57, 22 November 2024
Line 96:		Line 96:
	** Or any node with a complex child node hierarchy may be referred to as the "root" relative to one of its children (like the "root" extractor of a '''Data Type''' with multiple child '''Data Types''' and '''Value Readers).		** Or any node with a complex child node hierarchy may be referred to as the "root" relative to one of its children (like the "root" extractor of a '''Data Type''' with multiple child '''Data Types''' and '''Value Readers).
	\|}		\|}

	~~== Glossary ==~~
	~~<u><big>'''Batch'''</big></u>: {{#lst:Glossary\|Batch}}~~

	~~<u><big>'''Content Model'''</big></u>: {{#lst:Glossary\|Content Model}}~~

	~~<u><big>'''Data Column'''</big></u>: {{#lst:Glossary\|Data Column}}~~

	~~<u><big>'''Data Field'''</big></u>: {{#lst:Glossary\|Data Field}}~~

	~~<u><big>'''Data Model'''</big></u>: {{#lst:Glossary\|Data Model}}~~

	~~<u><big>'''Data Section'''</big></u>: {{#lst:Glossary\|Data Section}}~~

	~~<u><big>'''Data Table'''</big></u>: {{#lst:Glossary\|Data Table}}~~

	~~<u><big>'''Data Type'''</big></u>: {{#lst:Glossary\|Data Type}}~~

	~~<u><big>'''File Store'''</big></u>: {{#lst:Glossary\|File Store}}~~

	~~<u><big>'''Grooper Repository'''</big></u>: {{#lst:Glossary\|Grooper Repository}}~~

	~~<u><big>'''Machine'''</big></u>: {{#lst:Glossary\|Machine}}~~

	~~<u><big>'''Node Tree'''</big></u>: {{#lst:Glossary\|Node Tree}}~~

	~~<u><big>'''Permission Sets'''</big></u>: {{#lst:Glossary\|Permission Sets}}~~

	~~<u><big>'''Project'''</big></u>: {{#lst:Glossary\|Project}}~~

	~~<u><big>'''Repository'''</big></u>: {{#lst:Glossary\|Repository}}~~

	~~<u><big>'''Root'''</big></u>: {{#lst:Glossary\|Root}}~~

	~~<u><big>'''UI Element'''</big></u>: {{#lst:Glossary\|UI Element}}~~

	~~<u><big>'''Value Reader'''</big></u>: {{#lst:Glossary\|Value Reader}}~~

← Older revision		Revision as of 09:57, 22 November 2024
Line 96:		Line 96:
	** Or any node with a complex child node hierarchy may be referred to as the "root" relative to one of its children (like the "root" extractor of a '''Data Type''' with multiple child '''Data Types''' and '''Value Readers).		** Or any node with a complex child node hierarchy may be referred to as the "root" relative to one of its children (like the "root" extractor of a '''Data Type''' with multiple child '''Data Types''' and '''Value Readers).
	\|}		\|}

	~~== Glossary ==~~
	~~<u><big>'''Batch'''</big></u>: {{#lst:Glossary\|Batch}}~~

	~~<u><big>'''Content Model'''</big></u>: {{#lst:Glossary\|Content Model}}~~

	~~<u><big>'''Data Column'''</big></u>: {{#lst:Glossary\|Data Column}}~~

	~~<u><big>'''Data Field'''</big></u>: {{#lst:Glossary\|Data Field}}~~

	~~<u><big>'''Data Model'''</big></u>: {{#lst:Glossary\|Data Model}}~~

	~~<u><big>'''Data Section'''</big></u>: {{#lst:Glossary\|Data Section}}~~

	~~<u><big>'''Data Table'''</big></u>: {{#lst:Glossary\|Data Table}}~~

	~~<u><big>'''Data Type'''</big></u>: {{#lst:Glossary\|Data Type}}~~

	~~<u><big>'''File Store'''</big></u>: {{#lst:Glossary\|File Store}}~~

	~~<u><big>'''Grooper Repository'''</big></u>: {{#lst:Glossary\|Grooper Repository}}~~

	~~<u><big>'''Machine'''</big></u>: {{#lst:Glossary\|Machine}}~~

	~~<u><big>'''Node Tree'''</big></u>: {{#lst:Glossary\|Node Tree}}~~

	~~<u><big>'''Permission Sets'''</big></u>: {{#lst:Glossary\|Permission Sets}}~~

	~~<u><big>'''Project'''</big></u>: {{#lst:Glossary\|Project}}~~

	~~<u><big>'''Repository'''</big></u>: {{#lst:Glossary\|Repository}}~~

	~~<u><big>'''Root'''</big></u>: {{#lst:Glossary\|Root}}~~

	~~<u><big>'''UI Element'''</big></u>: {{#lst:Glossary\|UI Element}}~~

	~~<u><big>'''Value Reader'''</big></u>: {{#lst:Glossary\|Value Reader}}~~

← Older revision		Revision as of 12:00, 28 April 2025
Line 64:		Line 64:
	=== More on parents and children ===		=== More on parents and children ===

	Parent nodes determine many things for their children. The parent node's ~~object~~ type dictates what its children can be. It controls what possible ~~object~~ types its child nodes can be. Parents and children will also pass information to each other in different ways, depending on their ~~object~~ types.		Parent nodes determine many things for their children. The parent node's type dictates what its children can be. It controls what possible node types its child nodes can be. Parents and children will also pass information to each other in different ways, depending on their types.

	The parent node will always determine what ~~object~~ types (if any) can be created as children.		The parent node will always determine what node types (if any) can be created as children.
	* This may be more restrictive.		* This may be more restrictive.
	** For Example: A '''Data Model''' can only have '''Data Field''', '''Data Section''' or '''Data Table''' nodes as its immediate children.		** For Example: A '''Data Model''' can only have '''Data Field''', '''Data Section''' or '''Data Table''' nodes as its immediate children.
Line 72:		Line 72:
	* This may be more permissive when the parent node is more of a folder organizing child nodes.		* This may be more permissive when the parent node is more of a folder organizing child nodes.
	** For Example: A '''Content Model's''' '''Local Resources''' folder or a '''Project''' node.		** For Example: A '''Content Model's''' '''Local Resources''' folder or a '''Project''' node.
	** Many different kinds of node ~~objects~~ can be added ~~as nodes in~~ a '''Local Resources''' folder.		** Many different kinds of node types can be added to a '''Local Resources''' folder.
	** Almost every type ~~of node object~~ can be added to a '''Project'''		** Almost every node type can be added to a '''Project'''

	The parent node's ~~object~~ type also determines what information is passed to and from the parent and child nodes.		The parent node's type also determines what information is passed to and from the parent and child nodes.
	* For Example: A '''Content Model''' will pass its '''''Export Behavior''''' configuration to child '''Document Types'''. This way users don't have to configure '''''Export Behavior''''' settings to multiple '''Document Types''' using the same export logic.		* For Example: A '''Content Model''' will pass its '''''Export Behavior''''' configuration to child '''Document Types'''. This way users don't have to configure '''''Export Behavior''''' settings to multiple '''Document Types''' using the same export logic.
	* For Example: a '''Data Type's''' children '''Value Readers''' will pass all results they return to the parent '''Data Type'''. Those results will then be collated according to the '''Data Type's''' configuration		* For Example: a '''Data Type's''' children '''Value Readers''' will pass all results they return to the parent '''Data Type'''. Those results will then be collated according to the '''Data Type's''' configuration