Differences

This shows you the differences between two versions of the page.

--- tutorials:rgg-code-structure [2024/10/11 12:37] – [Replacement rules] tim
+++ tutorials:rgg-code-structure [2025/01/10 11:16] (current) – gaetan
@@ Line 17: / Line 17: @@
 Additionally there are several functions predefined that can be used to change the behavior of the simulation. At this point we will only talk about the initialization: ''protected void init ()''. this function is executed after the compilation or a model reset.
+<code java>
+protected void init ()
+[
+	{println("hallo");}
+	Axiom ==> A(parameters.length);
+]
+</code>
+The Axiom is the node that is added to the graph in the very beginning of the simulation and is used as an access point.
 ===== Java blocks =====
@@ Line 68: / Line 76: @@
 ==== Queries ====
-In GroIMP the project graph is considered to hold almost all information on the simulation. Therefore it can also be seen as a knowledge graph. To retrieve this knowledge rgg uses the [[tutorials:common_graph_queries|XL query system]]. To use this queries in a java block they have to be framed by ''(*...*)'' as shown in the examples below. In that way they return a collection object, which then can be like other java objects. Moreover GroIMP comes with a set of predefined  [[groimp-platform:xl-operators|Analytical Operators]] to analyze this collections.
+In GroIMP the project graph is considered to hold almost all information on the simulation. Therefore it can also be seen as a knowledge graph. To retrieve this knowledge rgg uses the [[tutorials:common_graph_queries|XL query system]]. To use this queries in a java block they have to be framed by ''(*...*)'' as shown in the examples below. In that way they return a collection object, which then can be like other java objects. Moreover GroIMP comes with a set of predefined  [[:groimp-platform:xl-builtin-methods|Analytical methods]] to analyze this collections.
 As shown in the example below in ''%%count((*M*))%%'' this queries work with the concept of java objects. Therefore ''(*M*)'' is selecting all instances of Branch because Branch extends M. This also works with interfaces.
@@ Line 100: / Line 108: @@
 ===== XL Blocks =====
-While using XL rules mainly two operators are used: replacement rules(''%%==>%%'') and   execution rule (''%%::>%%'').
+While using XL queries mainly two rules are used: replacement rules(''%%==>%%'') and execution rule (''%%::>%%'').
@@ Line 111: / Line 119: @@
 The most noticeable difference between these edges is that a Node should always only have one successor child. Therefore branches are needed to grow into different directions based on the way nodes interpreted by the visualization. In very simple terms this interpretation means that the transformation (rotation, location ...) of a Node is the sum of all its predecessors.
-In our example that means that the first A on the right side would be moved a distance of ''x'' in the current rotation axis (based on the ''F(x)'') and be rotated  on the up/x axis by 30 (''RU(30)'') and on the head/z axis 90 (''RH(90)'') degrees.
+In our example the first A on the right side would be moved a distance of ''x'' in the current rotation axis (based on the ''F(x)'') and be rotated  on the up/x axis by 30 (''RU(30)'') and on the head/z axis 90 (''RH(90)'') degrees.
@@ Line 123: / Line 131: @@
 ==== Execution rule ====
+The left side of an execution rule is similar to the left side of the production rule. Yet the main difference is that the nodes (or pattern of nodes) found by the query are not replaced. Instead the code on the right side is applied on them.
 <code java>
 public void getDiameter()[
     	a:A::>{println(a.getDiameter());}
+]
+</code>
+This works very similar to looping over the result of the query. This also works with manipulation several nodes at the same time:
+<code java>
+public void change()[
+	l:RU h:RH ::> {
+		float a = h[angle];
+		h[angle]=l[angle];
+		l[angle]=a;
+	}
+]
+</code>
+==== Working with several Files ====
+{{ :tutorials:file_explorer.png?260|}}
+In GroIMP it is possible to split your code into several files and folders to improve the structure and keep an overview.
+<color #ed1c24>It is highly recommended to only have public void functions in one file. Otherwise your project will have several rest buttons that do different things... </color>
+To use function from another file this file needs to be imported similar to a java class or package.
+Yet in the case of GroIMP all files are imported by their name without the directories, therefore to import all modules, and classes in ''param/parameters.rgg'' you just write:
+<code java>
+import parameters.YourModule;
+</code>
+To get this a bit clearer lets assume our parameters.rgg file contains the following code:
+<code java>
+public static int length = 1;
+public static float diameter = 0.1;
+module Leaf() ==> leaf3d(1);
+module Shoot() extends F(1);
+</code>
+To import one specific object once, you can simply do ''parameters.length'' as for example in ''A(parameters.length'' in the new RGG project. Or to use module:
+<code java>
+protected void init ()
+[
+Axiom ==> parameters.Leaf();
+]
+</code>
+If you want to use your module several times you can also import it one in the beginning and then reuse it:
+<code java>
+import parameters.Leaf;
+protected void init ()
+[
+Axiom ==> Leaf()[RL(180) Leaf()];
+]
+</code>
+Finally you can import all modules with the * operator:
+<code java>
+import parameters.*;
+protected void init ()
+[
+Axiom ==> Shoot() Leaf()[RL(180) Leaf()];
+]
+</code>
+This can also be done with the static variables using static import:
+<code java>
+import static parameters.*;
+protected void init ()
+[
+	Axiom ==> F(length,diameter);
 ]
 </code>