From: Bruno Sinou <bsinou@argeo.org>
Date: Wed, 16 Feb 2011 18:37:00 +0000 (+0000)
Subject: add some comments to help understanding the approach
X-Git-Tag: argeo-slc-2.1.7~1029
X-Git-Url: http://git.argeo.org/?a=commitdiff_plain;ds=sidebyside;h=58efbefd4194e7b3b9da463964bd791a759702f2;p=gpl%2Fargeo-slc.git

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 187c36589..f43293099 100644
--- 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
  *