add some comments to help understanding the approach

git-svn-id: https://svn.argeo.org/slc/trunk@4151 4cfe0d0a-d680-48aa-b62c-e0a02a3f76cc

diff --git a/runtime/org.argeo.slc.specs/src/main/java/org/argeo/slc/execution/ExecutionFlowDescriptor.java b/runtime/org.argeo.slc.specs/src/main/java/org/argeo/slc/execution/ExecutionFlowDescriptor.java
index 187c3658966c29789fae23376c88af8ac34c7c0b..f4329309996bc9fd6ee855be9731415953bcf446 100644 (file)
--- a/runtime/org.argeo.slc.specs/src/main/java/org/argeo/slc/execution/ExecutionFlowDescriptor.java
+++ b/runtime/org.argeo.slc.specs/src/main/java/org/argeo/slc/execution/ExecutionFlowDescriptor.java
@@ -21,23 +21,24 @@ import java.util.Map;
 
 /**
  * 
- *         Implements both archetype and implementation of a given
- *         process.
+ * Implements both archetype and implementation of a given process.
  * 
- *         At specification time, <code>executionSpec</code> represents the spec
- *         of the parameters accepted by the process, with, among others: type,
- *         default value and, optionally, possible values for each parameter. Thus
- *         ExecutionSpec might be a huge object. Note that when marshalling only
- *         a reference to a specific ExecutionSpec is stored in the XML to
- *         optimize performance and avoid redundancy between various
- *         ExecutionFlowDesciptor that might have the same ExecutionSpec.
+ * At specification time, <code>executionSpec</code> represents the spec of the
+ * parameters accepted by the process, with, among others: type, default value
+ * and, optionally, possible values for each parameter. Thus ExecutionSpec might
+ * be a huge object. Note that when marshalling only a reference to a specific
+ * ExecutionSpec is stored in the XML to optimize performance and avoid
+ * redundancy between various ExecutionFlowDesciptor that might have the same
+ * ExecutionSpec.
  * 
- *         At runtime, we build a RealizedFlow which references an
- *         ExecutionFlowDescriptor. As it happens AFTER marshalling /
- *         unmarshalling process, the ExecutionSpec is null but we manage to
- *         retrieve the ExecutionSpec and store it in the RealizedFlow, whereas
- *         set values of the parameters are stored in the <code>values</code>
- *         map.
+ * At runtime, we build a RealizedFlow which references an
+ * ExecutionFlowDescriptor. As it happens AFTER marshalling / unmarshalling
+ * process, the ExecutionSpec is null but we manage to retrieve the
+ * ExecutionSpec and store it in the RealizedFlow, whereas set values of the
+ * parameters are stored in the <code>values</code> map.
+ * 
+ * Generally, values object are either a <code>PrimitiveAccessor</code> or a
+ * <code>RefValue</code> but can be other objects.
  * 
  * @author bsinou
  *