Code and Code again :)

How to simplify that?

	private TLTNode FillNode(ElseType myElse) {
		TLTNode node=new TLTNode();
		for(ExecType exec : myElse.getExecArray()){
			node.addExec(new TLTExec(exec.getId(),exec.getValue(),exec.getParam()));
		}
		for(IfType iflist : myElse.getIfArray()){
			node.addIf(fillIfs(iflist));
		}
		return node;
	}
	
	private TLTNode FillNode(ThenType myThen) {
		TLTNode node=new TLTNode();
		for(ExecType exec : myThen.getExecArray()){
			node.addExec(new TLTExec(exec.getId(),exec.getValue(),exec.getParam()));
		}
		for(IfType iflist : myThen.getIfArray()){
			node.addIf(fillIfs(iflist));
		}
		return node;
	}

The difference is only in the parameter.. Parameters are auto-generated types created by XMLBeans so we can't change it...
I've modified the schema to solve this.Now the else tag will contain an generated thenType.. might be confusing in the code but it solves the complexity. See the attached schema for the changes. Problem solved

 <xs:complexType name="ifType">
    <xs:sequence>
      <xs:element type="tas:thenType" name="then" xmlns:tas="http://www.w3.org/unicorn/tasklist"/>
      <xs:element type="tas:thenType" name="else" xmlns:tas="http://www.w3.org/unicorn/tasklist"/>
    </xs:sequence>
    <xs:attribute type="xs:string" name="test"/>
  </xs:complexType>

---

I'm coding the relation between the if value attributes and the conds nodes.
As we build the tree we have insert the cond in it and therefore we'll have to find the cond node by ourselves.
We won't need the # in the if statement anymore. Here is the new XML sample for the tasklist.

---

The Task tree is implemented , filled and tested. Everything works fine by now.

---

We had to change the schema once more to take into account the fact that an exec tag concerns another task OR an observer.
Then we added a type attribute to resolve it. Possible values are -> subtask OR observer
You can find the new schema here.

<exec id="so_known_whatever3" value="css-validator" type="subtask" />

---

Currently doing the tasklist.Task coupled with the UnmarshallerBeans?.Right now the Unmarshaller fills the MapOfObservation? of the tasklist.Task by parsing the generated JAXB Task.
Now , what we've done is to create the whole tree of execution level in the constructor of the tasklist.Task. Then to list the observation we just have to browse the tree.
Is that too much responsibility for the tasklist.Task object? Should we continue to do it in the unmarshaller?

---

The tasklist.Observation represent an observation with the different mimetype handling priority.
With our solution , an observation is almost like an exec tag in the new tasklist.
Then the tasklist.Observation will become much much simpler.
However we may create new classes to deal with the execution level to deal with the different Observation.
Any ideas on that? The simplification of the Observation Class affects the RDFUnmarshallerjena class and Unicorn Call of course.
I'll take a look at that.
What to do with the mimetypes? should we erase it? or keep it for other purposes. The RDFUnmarshaller allows to add mimetype handling to a task and therefore to an observation. The mimetypes could stay in order to test if the observer really handles the mimetype we're giving.
The RDF in in unicorn.conf.Task.rdfs define priorities and mimetypes.. We'll have to change all the RDF handling too.

I've erased all the trace of mimetypes in the Observation class, and in the unicorn.cond.Task.rdfs. I may emulate the mimetypes check to know if an observer can handle specific mimetypes.

---

In the UnicornCall? we should adapt the RequestList?. In the GenerateRequestList? , we'd add observation with their level of execution as a key
Therefore in the doTask method we'll loop till the level of execution exist
I think that's the solution that doesn't damage much the existing code and would be as effective
Whereas this would erase the behaviour with the 3 priorities Maps.

---